I'm using smartd to monitor my HD, and want it to send an email message to another address if an error occirs. I've specified the non-local recipient in smartd.conf correctly. Problem is that when mail sends the message, it sends it as being from "root@localhost.localdomain" - which of course is rejected as invalid at the receiving host.
How do I get mail to use my *real* address?
Thanks
On Sun, 2005-10-30 at 03:31 -0600, Jay Moore wrote:
I'm using smartd to monitor my HD, and want it to send an email message to another address if an error occirs. I've specified the non-local recipient in smartd.conf correctly. Problem is that when mail sends the message, it sends it as being from "root@localhost.localdomain" - which of course is rejected as invalid at the receiving host.
How do I get mail to use my *real* address?
Thanks
Jay Moore jaymo@mail.bokler.com
edit /etc/aliases
on the bottom of the file their is typically an example for roots mail going to marc. Uncomment that line, substitute your local account name or ISP account name for that.
run newaliases
run logwatch
If you have any issues after this check your log files, but this should do the trick in most cases.
Ted
On Sun, 2005-10-30 at 04:44 -0500, Ted Kaczmarek wrote:
On Sun, 2005-10-30 at 03:31 -0600, Jay Moore wrote:
I'm using smartd to monitor my HD, and want it to send an email message to another address if an error occirs. I've specified the non-local recipient in smartd.conf correctly. Problem is that when mail sends the message, it sends it as being from "root@localhost.localdomain" - which of course is rejected as invalid at the receiving host.
How do I get mail to use my *real* address?
edit /etc/aliases
on the bottom of the file their is typically an example for roots mail going to marc. Uncomment that line, substitute your local account name or ISP account name for that.
run newaliases
run logwatch
If you have any issues after this check your log files, but this should do the trick in most cases.
I don't think that's the problem... changing that line would cause all of root's mail to go to another destination - that's not the problem. I'm trying to send a message from this host (aria.bokler.com) to my "real" email account on a different host.
The problem is that the from: address "mail" is using is bogus: "root@localhost.localdomain" Problem is that I don't know *where* mail is getting this address. Following is the error message:
----- The following addresses had permanent fatal errors ----- jaymo@mail.bokler.com (reason: 553 5.1.8 root@localhost.localdomain... Domain of sender address root@localhost.localdomain does not exist) jaymo@mail.bokler.com (reason: 501 root@localhost.localdomain... Sender domain must exist)
On Sun, 30 Oct 2005 04:03:29 -0600. Jay Moore waffled thusly:
On Sun, 2005-10-30 at 04:44 -0500, Ted Kaczmarek wrote:
On Sun, 2005-10-30 at 03:31 -0600, Jay Moore wrote:
<snip>
edit /etc/aliases
on the bottom of the file their is typically an example for roots mail going to marc. Uncomment that line, substitute your local account name or ISP account name for that.
run newaliases
run logwatch
If you have any issues after this check your log files, but this should do the trick in most cases.
I don't think that's the problem... changing that line would cause all of root's mail to go to another destination - that's not the problem. I'm trying to send a message from this host (aria.bokler.com) to my "real" email account on a different host.
The problem is that the from: address "mail" is using is bogus: "root@localhost.localdomain" Problem is that I don't know *where* mail is getting this address. Following is the error message:
----- The following addresses had permanent fatal errors ----- jaymo@mail.bokler.com (reason: 553 5.1.8 root@localhost.localdomain... Domain of sender address root@localhost.localdomain does not exist) jaymo@mail.bokler.com (reason: 501 root@localhost.localdomain... Sender domain must exist)
The remote server is well behaved. Good.
Change the references in /etc/smartd.conf accordingly:
eg.
/dev/hda -H -m root@localhost.localdomain /dev/hdc -H -m root@localhost.localdomain
becomes
/dev/hda -H -m me@domain.mumble.invalid # My email address goes here. /dev/hdc -H -m me@domain.mumble.invalid # and here
See smartd(8)
Cheers, Michael.
On Sun, 2005-10-30 at 20:52 +1000, Michael Fleming wrote:
The problem is that the from: address "mail" is using is bogus: "root@localhost.localdomain" Problem is that I don't know *where* mail is getting this address. Following is the error message:
----- The following addresses had permanent fatal errors ----- jaymo@mail.bokler.com (reason: 553 5.1.8 root@localhost.localdomain... Domain of sender address root@localhost.localdomain does not exist) jaymo@mail.bokler.com (reason: 501 root@localhost.localdomain... Sender domain must exist)
The remote server is well behaved. Good.
Change the references in /etc/smartd.conf accordingly:
eg.
/dev/hda -H -m root@localhost.localdomain /dev/hdc -H -m root@localhost.localdomain
becomes
/dev/hda -H -m me@domain.mumble.invalid # My email address goes here. /dev/hdc -H -m me@domain.mumble.invalid # and here
See smartd(8)
No - sorry - that's not it either... I don't have a "root@localhost..." email address in the list. Here's the line from smartd.conf:
/dev/hda -H -m jaymo@mail.bokler.com,root@aria.bokler.com
The email address that bounces (as in the error message above) is the first one (a valid address). aria is on the "private" network, and has no dns record anywhere.
It seems the problem is either a) cannot specify a "From:" address for 'mail', or b) I need something else in /etc/hosts (or resolv.conf) files.
Oddly, my email client on aria is able to send mail just fine. And the Windows boxes on the network that use 'blat' can send mail just fine.
Puzzledly, Jay
On Sun, Oct 30, 2005 at 04:03:29AM -0600, Jay Moore wrote:
The problem is that the from: address "mail" is using is bogus: "root@localhost.localdomain" Problem is that I don't know *where* mail is getting this address. Following is the error message:
Well, it's not exactly bogus... It's what your machine is configured to use. :)
The problem is that the hostname of your system is localhost.localdomain as determined in /etc/hosts and/or /etc/resolv.conf and/or /etc/sysconfig/network, and smartd is running as root, so it will send mail out as root@localhost.localdomain. This is normal and expected.
You need to do one of the following:
- change the hostname of your machine to something in a real domain - configure sendmail to masquerade your hostname/domain AND get rid of root as an "exposed user" - stop trying to send mail to legitimate Internet hosts from an illegitimate Internet host. ;-)
Probably the easiest thing to do is to change your hostname, but you'll have to pick some existing domain name to use. You'll need to change localhost.localdomain to your new hostname in all 3 of the locations I mentioned, except that you need to keep the following in /etc/hosts:
127.0.0.1 localhost localhost.localdomain
The entry for "localhost" is required for TCP/IP networking to work properly, and Red Hat has configured some of its software to use "localhost.localdomain" (which I always thought was brain-damaged), so you'll need that in there as well.
Let's say you choose the name myhost.mydomain.com as your new host name. If you have a static IP address, you can just add a line to /etc/hosts with the new name and your IP:
127.0.0.1 localhost localhost.localdomain 10.0.0.1 myhost.mydomain.com myhost
Otherwise if you get your Internet-facing IP address via DHCP, you'll want to add the name to the end of the 127.0.0.1 line, like this:
127.0.0.1 localhost localhost.localdomain myhost.mydomain.com myhost
After fixing the other two files, replacing any instances of localdomain with mydomain.com and instances of localhost.localdomain with myhost.mydomain.com, you should be all set.
One other possibility is that you may have to change your sendmail configuration even if you do this. In /etc/mail/sendmail.mc, you may have a line that says this:
LOCAL_DOMAIN(`localhost.localdomain')dnl
You'll probably need to change that too, and then run "make" in /etc/mail, then restart sendmail. If you have that line in /etc/mail/submit.mc as well, you'll probably need to change it there too.
HTH
On Sun, 2005-10-30 at 12:06 -0500, Derek Martin wrote:
Red Hat has configured some of its software to use "localhost.localdomain" (which I always thought was brain-damaged), so you'll need that in there as well.
I can see why they've done something *like* that, as there's some networking things that will insist on there being at least one dot in the name, but I would have done it differently.
e.g. machinename.localhost
That would have used a name set aside (localhost) as a domain name that won't be used on the internet, satisfied the need for a dot in the name, made a sensible domain name structure for local networks, and doesn't prevent "localhost" from being used for 127.0.0.1. ;-\
On Mon, Oct 31, 2005 at 11:38:50PM +1030, Tim wrote:
On Sun, 2005-10-30 at 12:06 -0500, Derek Martin wrote:
Red Hat has configured some of its software to use "localhost.localdomain" (which I always thought was brain-damaged), so you'll need that in there as well.
I can see why they've done something *like* that, as there's some networking things that will insist on there being at least one dot in the name, but I would have done it differently.
Hmm... can you provide an example? I've never seen such a beast that I'm aware of. And IMO you shouldn't... localhost is localhost -- it isn't in a domain; that's the whole point. The entire 127.0.0.0/8 network refers to your local machine. I'm inclined to think that software which requires a domain is broken.
-- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D
Derek Martin:
Red Hat has configured some of its software to use "localhost.localdomain" (which I always thought was brain-damaged)
Tim:
I can see why they've done something *like* that, as there's some networking things that will insist on there being at least one dot in the name, but I would have done it differently.
Derek Martin:
Hmm... can you provide an example?
I can't remember off the top of my head, but one mail client, at least, flatly refused to allow me to specify localhost as the mail server. You had to have at least one dot in the name before it'd let you continue on configuring the client.
And IMO you shouldn't... localhost is localhost -- it isn't in a domain; that's the whole point. The entire 127.0.0.0/8 network refers to your local machine.
See RFC 2606: http://www.faqs.org/rfcs/rfc2606.html But note "traditional" and the warning off (which doesn't explicitly preclude it's use, that way).
What is needed is a reserved domain name for local hosting of servers, "localhost" fits the description rather well, for picking a name for intuitive reasons. It doesn't necessarily have to me the same machine, just something that's local.
I'm inclined to think that software which requires a domain is broken.
There's any number of things that want a FQDN, mail servers being the first thing that springs to mind.
On Wed, Nov 02, 2005 at 12:29:14AM +1030, Tim wrote:
I can see why they've done something *like* that, as there's some networking things that will insist on there being at least one dot in the name, but I would have done it differently.
Derek Martin:
Hmm... can you provide an example?
I can't remember off the top of my head, but one mail client, at least, flatly refused to allow me to specify localhost as the mail server. You had to have at least one dot in the name before it'd let you continue on configuring the client.
Well, I think that's broken. Reason: it's very possible to have an internal mail system which does not connect to the Internet and therefore does not need FQDNs. Granted, that probably doesn't happen much these days, but the option should exist.
And IMO you shouldn't... localhost is localhost -- it isn't in a domain; that's the whole point. The entire 127.0.0.0/8 network refers to your local machine.
See RFC 2606: http://www.faqs.org/rfcs/rfc2606.html But note "traditional" and the warning off (which doesn't explicitly preclude it's use, that way).
I'm not sure what you're trying to say here. My reading of the RFC agrees with what I wrote above. If your point was something different, then I guess I'll have to ask you to clarify...
What is needed is a reserved domain name for local hosting of servers,
Why? If the hosts are on a network which is connected to the Internet, they'll have their own domain already. If they're not, then no domain is needed. Or, if for the convenience of managing your network, having domains makes sense, then you should register a domain name anyway, even if you're not going to use it on the Internet. That way, if a time comes when you WANT to connect those systems to the 'Net, you don't need to reconfigure them all.
"localhost" fits the description rather well, for picking a name for intuitive reasons. It doesn't necessarily have to me the same machine, just something that's local.
I still don't see the need...
I'm inclined to think that software which requires a domain is broken.
There's any number of things that want a FQDN, mail servers being the first thing that springs to mind.
I can't speak for all mail server software, but I'm pretty sure sendmail doesn't require an FQDN. Which would make sense, since it was written at a time when there were like 12 machines connected to the Internet, and there were no FQDN's. :) And again, for those who don't need to be connected to the Internet, this should not be a requirement. For those that do require it, I say they're broken. :)
The only server which SHOULD require a FQDN is the DNS server, for (hopefully) obvious reasons. :) But even then, "myhost" can be a top-level domain and have its own A record. That's just not a very useful way to manage DNS. Still, possible.
Derek Martin:
And IMO you shouldn't... localhost is localhost -- it isn't in a domain; that's the whole point. The entire 127.0.0.0/8 network refers to your local machine.
Tim:
See RFC 2606: http://www.faqs.org/rfcs/rfc2606.html But note "traditional" and the warning off (which doesn't explicitly preclude it's use, that way).
Derek, again:
I'm not sure what you're trying to say here. My reading of the RFC agrees with what I wrote above. If your point was something different, then I guess I'll have to ask you to clarify...
It doesn't explicitly say that localhost means 127.0.0.1, it says that it's a top level domain name. Commonly used for that purpose, and might not work well for other uses (actually used as a top level domain name), but it is one.
What is needed is a reserved domain name for local hosting of servers,
Why? If the hosts are on a network which is connected to the Internet, they'll have their own domain already. If they're not, then no domain is needed. Or, if for the convenience of managing your network, having domains makes sense, then you should register a domain name anyway, even if you're not going to use it on the Internet. That way, if a time comes when you WANT to connect those systems to the 'Net, you don't need to reconfigure them all.
A simple reason is the sheer number of LANs with an internet connection where some bozo has taken someone else's domain named and used it themselves, then misuses in public, too. Not to mention the problems they'll have with their own network when something resolves to an outside address.
I have my own domain name, and it certainly does make a lot of networking easier if you don't have to fiddle around doing daft things. You can use a real domain name in the same way as everywhere else, and don't have to use IP addresses.
There's any number of things that want a FQDN, mail servers being the first thing that springs to mind.
I can't speak for all mail server software, but I'm pretty sure sendmail doesn't require an FQDN. Which would make sense, since it was written at a time when there were like 12 machines connected to the Internet, and there were no FQDN's. :) And again, for those who don't need to be connected to the Internet, this should not be a requirement. For those that do require it, I say they're broken. :)
I seem to recall that if you do try using user@fakename sort of address, it'll try appending something to make a FQDN, presuming that anything without a dot is just an alias.
The only server which SHOULD require a FQDN is the DNS server, for (hopefully) obvious reasons. :) But even then, "myhost" can be a top-level domain and have its own A record. That's just not a very useful way to manage DNS. Still, possible.
Making up names leads to the problem I brought up. If you just invent something, it can clash with something else. Now, or later.
On Thu, Nov 03, 2005 at 07:27:19AM +1030, Tim wrote:
I'm not sure what you're trying to say here. My reading of the RFC agrees with what I wrote above. If your point was something different, then I guess I'll have to ask you to clarify...
It doesn't explicitly say that localhost means 127.0.0.1, it says that it's a top level domain name. Commonly used for that purpose, and might not work well for other uses (actually used as a top level domain name), but it is one.
OK... you're certainly able to use it that way if you like. It WILL work fine, if you set up your internal DNS server to be authoritative for the "localhost." zone (or use hosts files, or NIS, or ...), but honestly I still don't see the need.
What is needed is a reserved domain name for local hosting of servers,
Why? If the hosts are on a network which is connected to the Internet, they'll have their own domain already. If they're not, then no domain is needed. Or, if for the convenience of managing your network, having domains makes sense, then you should register a domain name anyway, even if you're not going to use it on the Internet. That way, if a time comes when you WANT to connect those systems to the 'Net, you don't need to reconfigure them all.
A simple reason is the sheer number of LANs with an internet connection where some bozo has taken someone else's domain named and used it themselves, then misuses in public, too.
Well, there are idiots everywhere. Those idiots would do just as well with their own genuine domain name as they would with some reserved one. Better, since as you say, they're actually using it on the Internet.
I think the problem is that idiots are idiots! It's not that we need another reserved TLD for this... Idiots don't tend to mind the standards anyway, largely because they're not aware of them in the first place... ;-)
Not to mention the problems they'll have with their own network when something resolves to an outside address.
Right. So it's better if they use a real domain... But as you say, there are several domains already reserved, so they can just use one of those. Or, just don't use one at all, and stop doing stupid things. ;-)
I can't speak for all mail server software, but I'm pretty sure sendmail doesn't require an FQDN.
I seem to recall that if you do try using user@fakename sort of address, it'll try appending something to make a FQDN [...]
Sure, it does that if you tell it to, and by default (since most people want to send e-mail on the public Internet) it's usually configured that way. But it doesn't need to be... You can tell it not to do that.
[...] presuming that anything without a dot is just an alias.
...though I'm not sure that it's making any such presumption. The usual reason to do this is because once mail from such a system hits the public internet, it's going to be hard to respond to if there's no FQDN in the headers. But still, sendmail has no trouble sending mail to unqualified hosts, so long as it can somehow resolve the unqualified name to an IP (usually via /etc/hosts or NIS, rather than DNS of course).
The only server which SHOULD require a FQDN is the DNS server, for (hopefully) obvious reasons. :) But even then, "myhost" can be a top-level domain and have its own A record. That's just not a very useful way to manage DNS. Still, possible.
Making up names leads to the problem I brought up. If you just invent something, it can clash with something else. Now, or later.
So... register a domain name. :) If you don't need one, don't use one at all. If you're going to send e-mail from your host without relaying through your ISP's mail server, or if you're going to run a server on your machine, then obviously you need one, and it MUST be legitimate. Otherwise, there's no reason why you should... Thusfar, I don't think you've provided any substantial reason why for a stand-alone network, one is required. And I assert that you will not find one. Though I've been wrong before... ;-)
It's been quite a while since I've tried to run my own system without a FQDN, so I don't remember the details, but IIRC the only time I've ever encountered a problem with not having a FQDN was with some (IMO) brain-dead, red-hat-specific software that was hard-coded to look for localhost.localdomain for some unknown reason. Normally when I install systems, whether my own or production servers, I remove the localhost.localdomain from the hosts file, and never have any problems. But Red Hat seems to like this convention for some reason, so you have to make sure all your software is not configured to use it. My normal solution to that problem is just not to use their system management software. ;-)
On Thu, 2005-11-03 at 13:41 -0500, Derek Martin wrote:
I don't think you've provided any substantial reason why for a stand-alone network, one is required. And I assert that you will not find one. Though I've been wrong before... ;-)
I'm sure someone could come up with a reason for a need for one, I certainly find having a local network domain name useful.
I run a small network, it has it's own DNS server, tied in with a DHCPD server. Guests get assigned IPs and names, as well as a domain name (it's filling in all the blanks, as far as networking is concerned). Most local machines have fixed addresses, though some are dynamic so I can test things out.
Determination of what is local or external is quite easy using either IP addresses or names, for filtering or other reasons (simple use the HTTP proxy, don't use the proxy, selections, etc.). Granted that either name or IP can be changed by malicious users, to sidestep filtering, but the chances of that are slim, here.
Having a domain name also avoids the nonsense you get when you call your mail server "mail" (sans-domain name) and your ISP does the same silly trick.
Since having a domain name is the norm, as far as internet-style networking is concerned. I'd say it's a bit of a bizarre want to avoid them.
On Fri, Nov 04, 2005 at 11:07:34PM +1030, Tim wrote:
On Thu, 2005-11-03 at 13:41 -0500, Derek Martin wrote:
I don't think you've provided any substantial reason why for a stand-alone network, one is required. And I assert that you will not find one. Though I've been wrong before... ;-)
I'm sure someone could come up with a reason for a need for one,
I'm sure they won't. ;-) I'm not saying they're not useful... obviously they are. But as for it being a technical requirement, there just isn't any. Except for broken software.
Maybe I haven't stated my points clearly. For point of clarification, by "broken software" I mean software which imposes an artificial technical limitation on its user, which does not exist outside the constraints of that software.
To clarify even further, TCP/IP networking does not in any way require FQDNs to work properly (see below for more on that). Therefore any software which absolutely mandates the use of FQDNs is broken, by the above definition. And that is true even if not using FQDNs is generally nonsensical in the usual case, to which I will stipulate. It remains true that, if I have my own personal TCP/IP network with no connection to the outside world, nothing will stop it from working properly without the use of FQDNs, except possibly for artificial limitations imposed by the application software.
It is even true that in most cases, it will work just fine on the public Internet as well, without locally using FQDNs for hostnames. The only exceptions to this are when using protocols that are intended to be multi-site, which are specifically designed to make use of DNS as a means of identifying the remote site uniquely. In most cases, this is done for reasons of authentication. It has already been shown by security researchers that relying on DNS information for host authentication is folly... so one can argue that this is an exception which should not exist, and should be fixed. But that's really beside the point.
I certainly find having a local network domain name useful.
Of course. I never said it wasn't useful. But if you're smart enough to realize the utility, why wouldn't you also be smart enough to realize that you should get your own, legitimate domain? It's not exactly expensive... so it's hard to argue that the cost is prohibitive. If you can afford the thousands of dollars to have the multiple computers neccessary to constitute a network (it ain't a network unless there are at least two computers involved), chances are you can afford a few bucks every year (or two) to register your own domain.
Remember also that my original point was primarily that under no circumstances is there any technical need for 127.0.0.0/8 to have a FQDN associated with it. It simply doesn't, and no matter how useful domain names are, that won't change. The purpose of that interface is solely to refer to one single machine, which can not possibly connect to other machines, so there is no sane reason why it should ever need a FQDN. The only reason it needs a name at all is because "localhost" is a lot easier to type than the IP address...
I only extended the argument to non-loopback interfaces because you insisted that a reserved domain name is needed for local networks; I don't agree, so I followed throuh to make the point: even when you ARE internetworking with a bunch of other machines, an FQDN is not strictly required. The entire DNS domain space was a construction that was created solely to make things more convenient for humans, because remembering hundreds or thousands of IP addresses is difficult (or impossible) for us. TCP/IP only cares about two things: IP addresses, and routes to get there. For local networks, DNS is utterly and completely unnecessary, and so too are FQDNs. If this were not true, MS Windows networking, which historically relied on netbios for name resolution and did not use DNS or FQDNs, would never have worked at all... But, while I won't comment about how WELL it worked, it did in fact work. ;-)
If you want to use a reserved domain for this purpose, there are several already, you're free to use one of those. But I think that's a bad idea. It's a lot of needless configuration, and if you should need to connect those systems to the net later, you'll just need to do it all over again. Better to have some forsight and get a real domain.
Having a domain name also avoids the nonsense you get when you call your mail server "mail" (sans-domain name) and your ISP does the same silly trick.
So use IP addresses instead. :-D
[Yes, sendmail allows this, if configured properly, though no sane person would ever do it.]
Since having a domain name is the norm, as far as internet-style networking is concerned. I'd say it's a bit of a bizarre want to avoid them.
Well, at the risk of sounding like a broken record, to sum it all up: If you are not participating in the public Internet, there simply is NO NEED to have one, and I can't even think of a useful purpose that it serves to have a fake one, if your network consists of only a handful of hosts. So if you are avoiding registering a legitimate one for some valid reason, you may as well not use one at all, and stick to hostnames only. If you ARE participating in the public Internet, you should have a LEGITIMATE domain. None of this necessitates a FQDN for 127.0.0.1, and nothing ever will, other than broken software.
Derek Martin:
To clarify even further, TCP/IP networking does not in any way require FQDNs to work properly (see below for more on that). Therefore any software which absolutely mandates the use of FQDNs is broken, by the above definition.
While agree that you can use IP addresses, with no absolute need for names, if you're using names then there probably are cases that a FQDN is essential. Though, one could well be a FQDN without subdomains: e.g. "localhost." (deliberate trailing dot).
Tim:
I certainly find having a local network domain name useful.
Of course. I never said it wasn't useful. But if you're smart enough to realize the utility, why wouldn't you also be smart enough to realize that you should get your own, legitimate domain? It's not exactly expensive... so it's hard to argue that the cost is prohibitive. If you can afford the thousands of dollars to have the multiple computers neccessary to constitute a network (it ain't a network unless there are at least two computers involved), chances are you can afford a few bucks every year (or two) to register your own domain.
I'll take that as being a statement "in general", I've already said that I have a real domain name.
Remember also that my original point was primarily that under no circumstances is there any technical need for 127.0.0.0/8 to have a FQDN associated with it.
On one PC that I have, it didn't associate "localhost" with the 127.0.0.1 local loopback address until I wrote a hosts file. That surprised me, I though it was built in, by default.
I only extended the argument to non-loopback interfaces because you insisted that a reserved domain name is needed for local networks; I don't agree, so I followed throuh to make the point: even when you ARE internetworking with a bunch of other machines, an FQDN is not strictly required.
I still maintain that it would be a good idea to have a reserved name for LANs. It would stop some people from making up arbitrary, and problematic ones, if there was already a predetermined one for common use that they might use in their recipe-book style of how to set up a network instructions that people seem to follow.
Imagine the mess we'd be in if nobody used "localhost" and one person would advise you to test something against "localhost" and the other would say "huh?" It gives you a common, simple, starting point.
For local networks, DNS is utterly and completely unnecessary, and so too are FQDNs.
I'm not so sure that I'd go along with that. Try booting up a graphical Linux client station without a hostname associated with a local IP address, and you're in for a bit of grief. It doesn't like the idea of you being user at 127.0.0.1 or unresolveable hostname.
While you might argue it's not an essential thing, I'd say that it's an established behaviour for so many years, now, that to suggest it should work in some other way is talking to a brick wall.
If you want to use a reserved domain for this purpose, there are several already, you're free to use one of those. But I think that's a bad idea. It's a lot of needless configuration, and if you should need to connect those systems to the net later, you'll just need to do it all over again. Better to have some forsight and get a real domain.
Now, I would agree with that. But a few years ago, here, registering a domain name was an expensive process. It still can be (we'd be paying $100 for what other countries charge $1).
Well, at the risk of sounding like a broken record, to sum it all up: If you are not participating in the public Internet, there simply is NO NEED to have one, and I can't even think of a useful purpose that it serves to have a fake one, if your network consists of only a handful of hosts.
Testing SSL communications, in-house. They need domain names for the certificates. :-p
So if you are avoiding registering a legitimate one for some valid reason, you may as well not use one at all, and stick to hostnames only. If you ARE participating in the public Internet, you should have a LEGITIMATE domain. None of this necessitates a FQDN for 127.0.0.1, and nothing ever will, other than broken software.
I'm not sure why 127.0.0.1 comes into the argument. I was talking about local networks, not just the one machine.
On Sat, Nov 05, 2005 at 11:12:45PM +1030, Tim wrote:
For local networks, DNS is utterly and completely unnecessary, and so too are FQDNs.
I'm not so sure that I'd go along with that. Try booting up a graphical Linux client station without a hostname associated with a local IP address, and you're in for a bit of grief. It doesn't like the idea of you being user at 127.0.0.1 or unresolveable hostname.
You have made a fatal error here... You are equating hostnames with fully qualified domain names. They are not the same. It is perfectly acceptable to have a hostname which is not a fully qualified domain name, and X will not have any problems dealing with that, so long as there is some method of resolving it to an IP address on your host (of which there are many other than DNS: host files, NIS, NIS+, LDAP, netbios, Active Directory, etc., etc.). DNS and BIND are far from the only name-resoultion game in town... But it is the only one that uses FQDNs.
DNS works fantastically well for the Internet, where as the other schemes generally could not. But, they are perfectly valid and useful for local networks.
a bad idea. It's a lot of needless configuration, and if you should need to connect those systems to the net later, you'll just need to do it all over again. Better to have some forsight and get a real domain.
Now, I would agree with that. But a few years ago, here, registering a domain name was an expensive process. It still can be (we'd be paying $100 for what other countries charge $1).
Then register it in a different country! ;-) I know people from the US who've registered domains in France, and other places... We live in a global community now. You are not bound by your country's borders any longer! ...and there was much rejoicing. :)
Well, at the risk of sounding like a broken record, to sum it all up: If you are not participating in the public Internet, there simply is NO NEED to have one, and I can't even think of a useful purpose that it serves to have a fake one, if your network consists of only a handful of hosts.
Testing SSL communications, in-house. They need domain names for the certificates. :-p
No, they need X.509 Distinguished Names. That's also not the same as a FQDN, even if most every site uses their FQDN as their DN. Internally, your DN need only match your internal host resolution scheme, which could be X.509 itself (which generally has been replaced by LDAP), and need not make use of DNS whatsoever. Sorry Charlie, but nice try. ;-)
So if you are avoiding registering a legitimate one for some valid reason, you may as well not use one at all, and stick to hostnames only. If you ARE participating in the public Internet, you should have a LEGITIMATE domain. None of this necessitates a FQDN for 127.0.0.1, and nothing ever will, other than broken software.
I'm not sure why 127.0.0.1 comes into the argument. I was talking about local networks, not just the one machine.
Because you were responding to my original post, where I said that I thought the whole idea of localhost.localdomain (vs. simply localhost) is brain-damaged. That's what started this thread.
On Thu, 2005-11-03 at 07:27 +1030, Tim wrote:
I seem to recall that if you do try using user@fakename sort of address, it'll try appending something to make a FQDN, presuming that anything without a dot is just an alias.
It occurs to me, now, that it might be "mail" not "sendmail" making that presumption.
On Sun, 2005-10-30 at 12:06 -0500, Derek Martin wrote:
On Sun, Oct 30, 2005 at 04:03:29AM -0600, Jay Moore wrote:
The problem is that the from: address "mail" is using is bogus: "root@localhost.localdomain" Problem is that I don't know *where* mail is getting this address. Following is the error message:
Well, it's not exactly bogus... It's what your machine is configured to use. :)
The problem is that the hostname of your system is localhost.localdomain as determined in /etc/hosts and/or /etc/resolv.conf and/or /etc/sysconfig/network, and smartd is running as root, so it will send mail out as root@localhost.localdomain. This is normal and expected.
You need to do one of the following:
- change the hostname of your machine to something in a real domain
- configure sendmail to masquerade your hostname/domain AND get rid of root as an "exposed user"
- stop trying to send mail to legitimate Internet hosts from an illegitimate Internet host. ;-)
I don't believe you've got it, Derek. At any rate, none of the things you prescribed seem to make any difference. Here are some facts I should have provided in my OP:
This host (aria) has a dynamic IP. It is on a private net, currently @ 192.168.1.207
my /etc/hosts file: 127.0.0.1 localhost localhost.localdomain aria.cullmail.com aria
my /etc/resolv.conf file: ; generated by /sbin/dhclient-script search cullmail.com nameserver 207.203.159.252 nameserver 205.152.0.5
my /etc/sysconfig/network file: NETWORKING=yes # HOSTNAME=localhost.localdomain HOSTNAME=aria.cullmail.com
I set up masquerading in /etc/mail/sendmail.mc, "re-compiled", re- started sendmail, re-booted, jumped up turned around three times with my left index finger on my nose while chanting "there's no place like home, there's no place like home". No dice... I even changed the .mc file so that *no reference* to localhost.localdomain existed in sendmail.cf (checked this w/ a grep).
So here's the thing: Evolution is configured to use sendmail on this host... it works fine. However 'pine' and 'mail' cannot get anything except 'localhost.localdomain' when they send mail.
Please clue me in if you can.
Jay
Probably the easiest thing to do is to change your hostname, but you'll have to pick some existing domain name to use. You'll need to change localhost.localdomain to your new hostname in all 3 of the locations I mentioned, except that you need to keep the following in /etc/hosts:
127.0.0.1 localhost localhost.localdomain
The entry for "localhost" is required for TCP/IP networking to work properly, and Red Hat has configured some of its software to use "localhost.localdomain" (which I always thought was brain-damaged), so you'll need that in there as well.
Let's say you choose the name myhost.mydomain.com as your new host name. If you have a static IP address, you can just add a line to /etc/hosts with the new name and your IP:
127.0.0.1 localhost localhost.localdomain 10.0.0.1 myhost.mydomain.com myhost
Otherwise if you get your Internet-facing IP address via DHCP, you'll want to add the name to the end of the 127.0.0.1 line, like this:
127.0.0.1 localhost localhost.localdomain myhost.mydomain.com myhost
After fixing the other two files, replacing any instances of localdomain with mydomain.com and instances of localhost.localdomain with myhost.mydomain.com, you should be all set.
One other possibility is that you may have to change your sendmail configuration even if you do this. In /etc/mail/sendmail.mc, you may have a line that says this:
LOCAL_DOMAIN(`localhost.localdomain')dnl
You'll probably need to change that too, and then run "make" in /etc/mail, then restart sendmail. If you have that line in /etc/mail/submit.mc as well, you'll probably need to change it there too.
HTH
Jay Moore wrote:
On Sun, 2005-10-30 at 12:06 -0500, Derek Martin wrote: This host (aria) has a dynamic IP. It is on a private net, currently @ 192.168.1.207
my /etc/hosts file: 127.0.0.1 localhost localhost.localdomain aria.cullmail.com aria
my /etc/resolv.conf file: ; generated by /sbin/dhclient-script search cullmail.com nameserver 207.203.159.252 nameserver 205.152.0.5
my /etc/sysconfig/network file: NETWORKING=yes # HOSTNAME=localhost.localdomain HOSTNAME=aria.cullmail.com
I set up masquerading in /etc/mail/sendmail.mc, "re-compiled", re- started sendmail, re-booted, jumped up turned around three times with my left index finger on my nose while chanting "there's no place like home, there's no place like home". No dice... I even changed the .mc file so that *no reference* to localhost.localdomain existed in sendmail.cf (checked this w/ a grep).
So here's the thing: Evolution is configured to use sendmail on this host... it works fine. However 'pine' and 'mail' cannot get anything except 'localhost.localdomain' when they send mail.
Please clue me in if you can.
For root, you can't get away with just eliminating "root" as an EXPOSED_USER in sendmail.mc and relying on MASQUERADE_DOMAIN because that will result in translating root@localhost.localdomain" to "root@some.real.host", which would be very wrong.
You can use genericstable to translate root@localhost.localdomain to some other real address. You'll want to uncomment the "FEATURE(`genericstable')" line in your sendmail.mc and include a line like the following in /etc/mail/genericstable:
root@localhost.localdomain somebody@some.real.domain.tld
You'll also need to uncomment the "FEATURE(`masquerade_envelope')" line in sendmail.mc and be sure "localhost.localdomain" is being included in class {G} by including a line: "GENERICS_DOMAIN(localhost.localdomain)dnl" (You can also use a GENERICS_DOMAIN_FILE to do that.)
I'm tempted to say, "Now rebuild sendmail.cf, restart sendmail, and Bob's your uncle," but (a) I'm not your uncle, and (b) I might have left something out. So, I won't.
On Sun, Nov 06, 2005 at 12:05:11PM -0600, Robert Nichols wrote:
For root, you can't get away with just eliminating "root" as an EXPOSED_USER in sendmail.mc and relying on MASQUERADE_DOMAIN because that will result in translating root@localhost.localdomain" to "root@some.real.host", which would be very wrong.
This is absolutely true, positively. Except that for Jay's purposes, it probably doesn't matter. If he's only trying to send mail out to himself, and will be careful not to use the address for any other purpose (i.e. he doesn't intend to reply to the message) then it doesn't really matter what the address is, so long as it is a "valid" one (in this case, not localhost.localdomain, and probably something that's resolvable, depending on his ISP).
Strictly speaking, to solve Jay's problem, all that is really required is to make sendmail stop sending mail out as localhost.localdomain. I believe that the easiest solution to that problem *should* be to just set LOCAL_DOMAIN to some reasonable value in the *.mc files, re-make the config files, and restart sendmail. Even masquerading really shouldn't be necessary. All that extra stuff I suggested before is probably not all that helpful... I must have had too much tequila when I wrote it. ;-) Sorry.
That said...
You can use genericstable to translate root@localhost.localdomain to some other real address. You'll want to uncomment the "FEATURE(`genericstable')" line in your sendmail.mc and include a line like the following in /etc/mail/genericstable:
root@localhost.localdomain somebody@some.real.domain.tld
This is good advice, and should work. It's probably the Right Thing(tm), barring registering one's own domain and getting it to resolve properly.
Derek Martin wrote:
On Sun, Nov 06, 2005 at 12:05:11PM -0600, Robert Nichols wrote:
For root, you can't get away with just eliminating "root" as an EXPOSED_USER in sendmail.mc and relying on MASQUERADE_DOMAIN because that will result in translating root@localhost.localdomain" to "root@some.real.host", which would be very wrong.
This is absolutely true, positively. Except that for Jay's purposes, it probably doesn't matter. If he's only trying to send mail out to himself, and will be careful not to use the address for any other purpose (i.e. he doesn't intend to reply to the message) then it doesn't really matter what the address is, so long as it is a "valid" one (in this case, not localhost.localdomain, and probably something that's resolvable, depending on his ISP).
Strictly speaking, to solve Jay's problem, all that is really required is to make sendmail stop sending mail out as localhost.localdomain. I believe that the easiest solution to that problem *should* be to just set LOCAL_DOMAIN to some reasonable value in the *.mc files, re-make the config files, and restart sendmail. Even masquerading really shouldn't be necessary.
That would be true if the mail were being submitted from "root". If the submission is from "root@localhost.localdomain" then the bare minimum requirement would be masquerading (without "root" as an EXPOSED_USER) to map that to "root@something.else". Without knowing exactly how the mail is being submitted there's no way to know whether that would work.
On Sun, 2005-11-06 at 18:36 -0600, Robert Nichols wrote:
Derek Martin wrote:
On Sun, Nov 06, 2005 at 12:05:11PM -0600, Robert Nichols wrote:
For root, you can't get away with just eliminating "root" as an EXPOSED_USER in sendmail.mc and relying on MASQUERADE_DOMAIN because that will result in translating root@localhost.localdomain" to "root@some.real.host", which would be very wrong.
This is absolutely true, positively. Except that for Jay's purposes, it probably doesn't matter. If he's only trying to send mail out to himself, and will be careful not to use the address for any other purpose (i.e. he doesn't intend to reply to the message) then it doesn't really matter what the address is, so long as it is a "valid" one (in this case, not localhost.localdomain, and probably something that's resolvable, depending on his ISP).
Strictly speaking, to solve Jay's problem, all that is really required is to make sendmail stop sending mail out as localhost.localdomain. I believe that the easiest solution to that problem *should* be to just set LOCAL_DOMAIN to some reasonable value in the *.mc files, re-make the config files, and restart sendmail. Even masquerading really shouldn't be necessary.
That would be true if the mail were being submitted from "root". If the submission is from "root@localhost.localdomain" then the bare minimum requirement would be masquerading (without "root" as an EXPOSED_USER) to map that to "root@something.else". Without knowing exactly how the mail is being submitted there's no way to know whether that would work.
The mail is being submitted by 'smartd', the smartmontools daemon... according to the docs, they use 'mail' (don't know why). Since smartd runs (at least starts) as root, I guess the message *is* being submitted from root.
Does that clarify anything?
Thanks, Jay
On Sun, 2005-11-06 at 21:20, Jay Moore wrote:
That would be true if the mail were being submitted from "root". If the submission is from "root@localhost.localdomain" then the bare minimum requirement would be masquerading (without "root" as an EXPOSED_USER) to map that to "root@something.else". Without knowing exactly how the mail is being submitted there's no way to know whether that would work.
The mail is being submitted by 'smartd', the smartmontools daemon... according to the docs, they use 'mail' (don't know why). Since smartd runs (at least starts) as root, I guess the message *is* being submitted from root.
Smartd has an option to invoke your own mail program. If you don't want to fix things in the mail transport you can send the output to a script or program that adds your choice of a 'From: address' before sending.
On Sun, 2005-11-06 at 22:24 -0600, Les Mikesell wrote:
On Sun, 2005-11-06 at 21:20, Jay Moore wrote:
That would be true if the mail were being submitted from "root". If the submission is from "root@localhost.localdomain" then the bare minimum requirement would be masquerading (without "root" as an EXPOSED_USER) to map that to "root@something.else". Without knowing exactly how the mail is being submitted there's no way to know whether that would work.
The mail is being submitted by 'smartd', the smartmontools daemon... according to the docs, they use 'mail' (don't know why). Since smartd runs (at least starts) as root, I guess the message *is* being submitted from root.
Smartd has an option to invoke your own mail program. If you don't want to fix things in the mail transport you can send the output to a script or program that adds your choice of a 'From: address' before sending.
That would be fine with me... do you have any suggestions for an alternative mail program?
Thanks, Jay
On Mon, 2005-11-07 at 22:08, Jay Moore wrote:
That would be true if the mail were being submitted from "root". If the submission is from "root@localhost.localdomain" then the bare minimum requirement would be masquerading (without "root" as an EXPOSED_USER) to map that to "root@something.else". Without knowing exactly how the mail is being submitted there's no way to know whether that would work.
The mail is being submitted by 'smartd', the smartmontools daemon... according to the docs, they use 'mail' (don't know why). Since smartd runs (at least starts) as root, I guess the message *is* being submitted from root.
Smartd has an option to invoke your own mail program. If you don't want to fix things in the mail transport you can send the output to a script or program that adds your choice of a 'From: address' before sending.
That would be fine with me... do you have any suggestions for an alternative mail program?
Just stick on the headers you want and feed it to "sendmail -t".
Call this mymailer and chmod +x:
#!/bin/sh (echo From: myfromaddress@mydomain echo To: mytoaddress@mydomain echo Subject: Something interesting echo cat ) |sendmail -t
That should mail anything you pipe to it using the sender address you want.
On Sun, 2005-11-06 at 12:05, Robert Nichols wrote:
So here's the thing: Evolution is configured to use sendmail on this host... it works fine. However 'pine' and 'mail' cannot get anything except 'localhost.localdomain' when they send mail.
Please clue me in if you can.
Evolution (and lots of other MUA's) allow you to specify your own 'From:' address. Anything that supports multiple accounts would have to. Pine probably has a way to do it but I'm not sure about 'mail' which might always assume the local host is your return address. If you can get the MUA to use your correct address in the first place, the transport won't have to correct it for you.
On Sat, Nov 05, 2005 at 11:55:01PM -0600, Jay Moore wrote:
You need to do one of the following:
- change the hostname of your machine to something in a real domain
- configure sendmail to masquerade your hostname/domain AND get rid of root as an "exposed user"
- stop trying to send mail to legitimate Internet hosts from an illegitimate Internet host. ;-)
I don't believe you've got it, Derek. At any rate, none of the things you prescribed seem to make any difference. Here are some facts I should have provided in my OP:
This host (aria) has a dynamic IP. It is on a private net, currently @ 192.168.1.207
This is probably not affecting your sendmail problem. It is more likely to do with your configuration of sendmail, specifically (but, see below where I talk about LOCAL_DOMAIN). That said, personally, I would probably make some changes anyway.
Is the DHCP server under your control? If so, I would configure it to assign a static IP address to your machine. Usually this involves telling it the MAC address of your NIC card. The details will unfortunately be server-dependent (and I suppose may be impossible with your particular DCHP server, though that would surprise me).
Then, assign your hostname (aria) to THAT IP address in your hosts file, e.g.:
my /etc/hosts file:
127.0.0.1 localhost 192.168.1.207 aria.cullmail.com aria
I set up masquerading in /etc/mail/sendmail.mc, "re-compiled", re-
But remember that mail from your local machine (by default on FCx installs) uses /etc/mail/submit.mc, as I mentioned in my previous post. What does that look like?
Also, sendmail decides what host it is using the LOCAL_DOMAIN macro. IIRC if this is not set, it will do some magic depending on how your system is configured to decide what your hostname is. In that case, changing the /etc/hosts file as I mentioned above may actually make a difference.
So, do you have LOCAL_DOMAIN set to something reasonable?
started sendmail, re-booted, jumped up turned around three times with my left index finger on my nose while chanting "there's no place like home, there's no place like home". No dice... I even changed the .mc file so that *no reference* to localhost.localdomain existed in sendmail.cf (checked this w/ a grep).
Sounds like fun, at least. ;-)
So here's the thing: Evolution is configured to use sendmail on this host... it works fine. However 'pine' and 'mail' cannot get anything except 'localhost.localdomain' when they send mail.
Pine can be configured to use whatever you want; it's a setting in Pine. /bin/mail just uses your username, and passes your mail on to sendmail to let it figure out how to address the mail. Pine will do this too, if you don't tell it not to.
Please clue me in if you can.
If none of this was helpful, I guess I'd have to see what was actually in both of your .mc files to be able to provide any more help.
Also, check to make sure your host name really is what you think it is, by typing
$ hostname
(you don't need to be root to use hostname this way, but you do if you want to set the hostname).
On Sun, 2005-11-06 at 13:36 -0500, Derek Martin wrote:
I set up masquerading in /etc/mail/sendmail.mc, "re-compiled", re-
But remember that mail from your local machine (by default on FCx installs) uses /etc/mail/submit.mc, as I mentioned in my previous post. What does that look like?
Not to be argumentative, but on my system (FC3, i386) which was "box stock" wrt sendmail configuration, here's what I see:
[root@aria jamoore]# cat /var/run/sendmail.pid 3367 /usr/sbin/sendmail -bd -q1h
IINM, the "-bd" says: sendmail is running as a "listener" (an actual mail server). Two thoughts come into my mind:
1) As a default configuration, why does FC* start sendmail w/ "-bd"?
2) Running as a listener (-bd), sendmail does not use submit.mc
As an aside: I did not change sendmail startup to use "-bd". So, how does sendmail get started on FC*? Let's see...
[root@aria jamoore]# cd /etc [root@aria etc]# grep -r 'sendmail -bd -q1h' * <snip some garbage> httpd/run/sendmail.pid:/usr/sbin/sendmail -bd -q1h
WTFO??? Where/how does sendmail get started?
Bottom Line: Having found this trove of knowledge, I *think* my best course of action is to fix (right after I find it) the sendmail startup to remove the "-bd" option, then start hacking submit.mc to fix my original problem.
If none of this was helpful, I guess I'd have to see what was actually in both of your .mc files to be able to provide any more help.
I'll be glad to post that if I can't do the deed
Also, check to make sure your host name really is what you think it is, by typing
$ hostname
[jamoore@aria ~]$ hostname aria.cullmail.com
I don't think it makes any difference to the receiving mail server whether or not aria.cullmail.com is an Internet-DNS-resolvable host... in any case, the connection will go through my firewall, and appear to come from that host.
Analysis or comments are welcome!
Jay
Jay Moore wrote:
Bottom Line: Having found this trove of knowledge, I *think* my best course of action is to fix (right after I find it) the sendmail startup to remove the "-bd" option,
Fine. Just don't bother others with complaints when mail within your own system (e.g., mail from cron jobs, mail from logwatch, etc.) just sits in /var/spool/clientmqueue and is never delivered.
FWIW, sendmail is a service started by 'init' in run levels 2-5. The files and links controlling that are in /etc/rc.d/init.d and /etc/rc.d/rc?.d . Unless you've changed the default setup, sendmail accept connections only from 127.0.0.1 .
On Mon, 2005-11-07 at 23:47 -0600, Robert Nichols wrote:
Jay Moore wrote:
Bottom Line: Having found this trove of knowledge, I *think* my best course of action is to fix (right after I find it) the sendmail startup to remove the "-bd" option,
Fine. Just don't bother others with complaints when mail within your own system (e.g., mail from cron jobs, mail from logwatch, etc.) just sits in /var/spool/clientmqueue and is never delivered.
!?! Are you saying that running sendmail without "-bd" will cause this?
According to the "sendmail Cookbook", "-bd" should not be used except for mail servers. Ref Chap. 10, "Securing sendmail".
FWIW, sendmail is a service started by 'init' in run levels 2-5. The files and links controlling that are in /etc/rc.d/init.d and /etc/rc.d/rc?.d . Unless you've changed the default setup, sendmail accept connections only from 127.0.0.1 .
As I stated previously, I have *not* changed my default setup for running sendmail. And pardon my bitching, but why the f**k do I have to hack a shell script to change the startup behavior? IMHO, this is BFU. Here's what I find in /etc/rc.d/init.d/sendmail... how would you suggest I change this?
[jamoore@aria ~]$ cat /etc/rc.d/init.d/sendmail #!/bin/bash # # sendmail This shell script takes care of starting and stopping # sendmail. # # chkconfig: 2345 80 30 # description: Sendmail is a Mail Transport Agent, which is the program \ # that moves mail from one machine to another. # processname: sendmail # config: /etc/mail/sendmail.cf # pidfile: /var/run/sendmail.pid
# Source function library. . /etc/rc.d/init.d/functions
# Source networking configuration. [ -f /etc/sysconfig/network ] && . /etc/sysconfig/network
# Source sendmail configureation. if [ -f /etc/sysconfig/sendmail ] ; then . /etc/sysconfig/sendmail else DAEMON=no QUEUE=1h fi [ -z "$SMQUEUE" ] && SMQUEUE="$QUEUE" [ -z "$SMQUEUE" ] && SMQUEUE=1h
# Check that networking is up. [ "${NETWORKING}" = "no" ] && exit 0
[ -f /usr/sbin/sendmail ] || exit 0
RETVAL=0 prog="sendmail"
start() { # Start daemons.
echo -n $"Starting $prog: " if test -x /usr/bin/make -a -f /etc/mail/Makefile ; then make all -C /etc/mail -s > /dev/null else for i in virtusertable access domaintable mailertable ; do if [ -f /etc/mail/$i ] ; then makemap hash /etc/mail/$i < /etc/mail/$i fi done fi /usr/bin/newaliases > /dev/null 2>&1 daemon /usr/sbin/sendmail $([ "x$DAEMON" = xyes ] && echo -bd) \ $([ -n "$QUEUE" ] && echo -q$QUEUE) $SENDMAIL_OPTARG RETVAL=$? echo [ $RETVAL -eq 0 ] && touch /var/lock/subsys/sendmail
if ! test -f /var/run/sm-client.pid ; then echo -n $"Starting sm-client: " touch /var/run/sm-client.pid chown smmsp:smmsp /var/run/sm-client.pid if [ -x /usr/bin/selinuxenabled ] && /usr/bin/selinuxenabled; then /sbin/restorecon /var/run/sm-client.pid fi daemon --check sm-client /usr/sbin/sendmail -L sm-msp-queue -Ac \ -q $SMQUEUE $SENDMAIL_OPTARG RETVAL=$? echo [ $RETVAL -eq 0 ] && touch /var/lock/subsys/sm-client fi
return $RETVAL }
On Tue, 2005-11-08 at 23:36, Jay Moore wrote:
Bottom Line: Having found this trove of knowledge, I *think* my best course of action is to fix (right after I find it) the sendmail startup to remove the "-bd" option,
Fine. Just don't bother others with complaints when mail within your own system (e.g., mail from cron jobs, mail from logwatch, etc.) just sits in /var/spool/clientmqueue and is never delivered.
!?! Are you saying that running sendmail without "-bd" will cause this?
Probably - anything that submits mail to the localhost via smtp will fail, and if you also take out the -q, or eliminat that process deliveries won't happen either.
According to the "sendmail Cookbook", "-bd" should not be used except for mail servers. Ref Chap. 10, "Securing sendmail".
They don't understand the setup where sendmail only listens on the localhost address.
FWIW, sendmail is a service started by 'init' in run levels 2-5. The files and links controlling that are in /etc/rc.d/init.d and /etc/rc.d/rc?.d . Unless you've changed the default setup, sendmail accept connections only from 127.0.0.1 .
As I stated previously, I have *not* changed my default setup for running sendmail. And pardon my bitching, but why the f**k do I have to hack a shell script to change the startup behavior? IMHO, this is BFU.
What? There is nothing easier than editing a text file. If you aren't able to do that, how do you manage to type all these messages? Almost every command you do on unix/linux systems is parsed by the shell before starting. Learning how the shell works can pay off every time you use it.
Here's what I find in /etc/rc.d/init.d/sendmail... how would you suggest I change this?
I'd suggest you leave it alone until you understand how to make it better. It works well enough as-is.
Jay Moore wrote:
And pardon my bitching, but why the f**k do I have tohack a shell script to change the startup behavior? IMHO, this is BFU.
Since you are apparently determined to make that change, you can do it by simply editing /etc/sysconfig/sendmail and changing the "DAEMON=yes" to "DAEMON=no" and restart the sendmail service. Then you can start making note of all the mail-related things that don't work any more on your system. There are ways to make mail work without that daemon process, but you have to set up a couple of other things to provide the necessary functions.
On Mon, 2005-11-07 at 22:55, Jay Moore wrote:
Bottom Line: Having found this trove of knowledge, I *think* my best course of action is to fix (right after I find it) the sendmail startup to remove the "-bd" option, then start hacking submit.mc to fix my original problem.
No, the only thing you need it fix is if you want to accept mail on addresses other than 127.0.0.1 and sendmail's idea of your hostname if it isn't what you want as a return address.
Also, check to make sure your host name really is what you think it is, by typing
$ hostname
[jamoore@aria ~]$ hostname aria.cullmail.comI don't think it makes any difference to the receiving mail server whether or not aria.cullmail.com is an Internet-DNS-resolvable host... in any case, the connection will go through my firewall, and appear to come from that host.
Most smtp receivers these days will not accept email if the sender's domain is not DNS-resolvable. Some sites will also refuse it if the IP and DNS don't match, but that is less common (and the RFC's explicitly permit that case - otherwise multihomed hosts wouldn't work).
On Tue, 2005-11-08 at 00:12 -0600, Les Mikesell wrote:
On Mon, 2005-11-07 at 22:55, Jay Moore wrote:
Bottom Line: Having found this trove of knowledge, I *think* my best course of action is to fix (right after I find it) the sendmail startup to remove the "-bd" option, then start hacking submit.mc to fix my original problem.
No, the only thing you need it fix is if you want to accept mail on addresses other than 127.0.0.1 and sendmail's idea of your hostname if it isn't what you want as a return address.
But that's just it - I *don't* want to accept mail on addresses other than lo (127.0.0.1). On this machine, I get my mail from a "real" (i.e. Internet DNS-resolvable) server via POP3. I only want to send mail from this host
Also, check to make sure your host name really is what you think it is, by typing
$ hostname
[jamoore@aria ~]$ hostname aria.cullmail.comI don't think it makes any difference to the receiving mail server whether or not aria.cullmail.com is an Internet-DNS-resolvable host... in any case, the connection will go through my firewall, and appear to come from that host.
Most smtp receivers these days will not accept email if the sender's domain is not DNS-resolvable. Some sites will also refuse it if the IP and DNS don't match, but that is less common (and the RFC's explicitly permit that case - otherwise multihomed hosts wouldn't work).
That's the problem - localhost.localdomain is not DNS-resolvable.
The most confusing thing to me now is this: if I send a message as a normal user from the 'mail' command line, it gets delivered just fine; the From: line in the header reflects that the message is from 'localhost.localdomain', but the receiving mail server sees it as ultimately from my NAT'ing firewall (frwl.cullmail.com).
However, if I send the message from the root account, it gets rejected by the destination host - the receiving host sees a From: header of 'localhost.localdomain'.
Why is this? Why is mail from root handled differently than mail from a regular user?
Thanks, Jay
On Tue, 2005-11-08 at 23:12, Jay Moore wrote:
No, the only thing you need it fix is if you want to accept mail on addresses other than 127.0.0.1 and sendmail's idea of your hostname if it isn't what you want as a return address.
But that's just it - I *don't* want to accept mail on addresses other than lo (127.0.0.1). On this machine, I get my mail from a "real" (i.e. Internet DNS-resolvable) server via POP3. I only want to send mail from this host
Then you just have to supply a usable 'From: ' header on the message as it is sent or have sendmail fix it on the way out.
Most smtp receivers these days will not accept email if the sender's domain is not DNS-resolvable. Some sites will also refuse it if the IP and DNS don't match, but that is less common (and the RFC's explicitly permit that case - otherwise multihomed hosts wouldn't work).
That's the problem - localhost.localdomain is not DNS-resolvable.
The most confusing thing to me now is this: if I send a message as a normal user from the 'mail' command line, it gets delivered just fine; the From: line in the header reflects that the message is from 'localhost.localdomain', but the receiving mail server sees it as ultimately from my NAT'ing firewall (frwl.cullmail.com).
However, if I send the message from the root account, it gets rejected by the destination host - the receiving host sees a From: header of 'localhost.localdomain'.
Why is this? Why is mail from root handled differently than mail from a regular user?
Your sendmail.mc probably has: MASQUERADE_AS(`frwl.cullmail.com') and EXPOSED_USER(`root') which says to change the From: header if it matches the local host name, except for the root user. If you have several machines with root's mail forwarded to a common location you might want to know where it came from. Rebuild without the EXPOSED_USER if you don't want that.
By the way, I don't see an MX or A record in DNS for frwl.cullmail.com.
On Sun, 2005-10-30 at 03:31 -0600, Jay Moore wrote:
I'm using smartd to monitor my HD, and want it to send an email message to another address if an error occirs. I've specified the non-local recipient in smartd.conf correctly. Problem is that when mail sends the message, it sends it as being from "root@localhost.localdomain" - which of course is rejected as invalid at the receiving host.
How do I get mail to use my *real* address?
I think you'll have to configure your sendmail (or equivalent) to masquerade outgoing mail as being from a specific domain (a real one that you own). It'd still come from root, but at a real domain that'd pass through most mail systems.
If you have your own domain, and your LAN makes use of it, why not configure your LAN to use it as your domain name? Then all local mail would work.
-
Derek Martin -
Jay Moore -
Les Mikesell -
Michael Fleming -
Robert Nichols -
Ted Kaczmarek -
Tim