mail confusion

[Jay Moore]

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(a)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(a)mail.bokler.com&gt;

[Ted Kaczmarek]

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(a)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(a)mail.bokler.com&gt;
>   
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

[Jay Moore]

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(a)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(a)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(a)mail.bokler.com&gt;
    (reason: 553 5.1.8 <[e-mail]>... Domain of sender
address
root(a)localhost.localdomain does not exist)
<jaymo(a)mail.bokler.com&gt;
    (reason: 501 <[e-mail]>... Sender domain must
exist)

[Michael Fleming]

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:
>  &quot;root(a)localhost.localdomain&quot;  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(a)mail.bokler.com&gt;
>      (reason: 553 5.1.8 <[e-mail]>... Domain of sender
>  address
>  root(a)localhost.localdomain does not exist)
>  <jaymo(a)mail.bokler.com&gt;
>      (reason: 501 <[e-mail]>... 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(a)localhost.localdomain
/dev/hdc -H -m root(a)localhost.localdomain

becomes

/dev/hda -H -m me(a)domain.mumble.invalid # My email address goes here.
/dev/hdc -H -m me(a)domain.mumble.invalid # and here

See smartd(8)

Cheers,
Michael.

-- 
Michael Fleming <mfleming(a)enlartenment.com&gt;
"Bother" said the Borg, "We've assimilated Pooh!"

[Jay Moore]

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(a)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(a)mail.bokler.com&gt;
>  >     (reason: 553 5.1.8 <[e-mail]>... Domain of sender
>  > address
>  > root(a)localhost.localdomain does not exist)
>  > <jaymo(a)mail.bokler.com&gt;
>  >     (reason: 501 <[e-mail]>... 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(a)localhost.localdomain
>  /dev/hdc -H -m root(a)localhost.localdomain
>  
>  becomes
>  
>  /dev/hda -H -m me(a)domain.mumble.invalid # My email address goes here.
>  /dev/hdc -H -m me(a)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 [e-mail],root(a)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

[Derek Martin]

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(a)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(a)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

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

[Tim]

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.  ;-\

-- 
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

[Derek Martin]

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

[Tim]

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.

-- 
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

[Derek Martin]

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 D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

[Tim]

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.

-- 
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

[Derek Martin]

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. ;-)

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

[Tim]

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.

-- 
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

[Derek Martin]

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 D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

[Tim]

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.

-- 
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

[Derek Martin]

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.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

[Tim]

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.

-- 
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

[Jay Moore]

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(a)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(a)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 <jaymo(a)mail.bokler.com&gt;

[Robert Nichols]

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(a)localhost.localdomain" to
"root(a)some.real.host", which would be very wrong.

You can use genericstable to translate root(a)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(a)localhost.localdomain   somebody(a)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.

-- 
Bob Nichols         Yes, "NOSPAM" is really part of my email address.

[Derek Martin]

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(a)localhost.localdomain" to
>  "root(a)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(a)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(a)localhost.localdomain   somebody(a)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 D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

[Robert Nichols]

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(a)localhost.localdomain" to
> >"root(a)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(a)localhost.localdomain" then the bare minimum
requirement would be masquerading (without "root" as an EXPOSED_USER)
to map that to "root(a)something.else".  Without knowing exactly how the
mail is being submitted there's no way to know whether that would work.

-- 
Bob Nichols         Yes, "NOSPAM" is really part of my email address.

[Jay Moore]

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(a)localhost.localdomain" to
>  >>"root(a)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(a)localhost.localdomain" then the bare minimum
>  requirement would be masquerading (without "root" as an EXPOSED_USER)
>  to map that to "root(a)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

[Les Mikesell]

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(a)localhost.localdomain" then the bare minimum
>  > requirement would be masquerading (without "root" as an EXPOSED_USER)
>  > to map that to "root(a)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.

-- 
  Les Mikesell
    lesmikesell(a)gmail.com

[Jay Moore]

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(a)localhost.localdomain" then the bare
> minimum
>  > > requirement would be masquerading (without "root" as an
> EXPOSED_USER)
>  > > to map that to "root(a)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

[Les Mikesell]

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(a)localhost.localdomain" then the bare
> minimum
>  > > > requirement would be masquerading (without "root" as an
> EXPOSED_USER)
>  > > > to map that to "root(a)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.  

-- 
  Les Mikesell
   lesmikesell(a)gmail.com

[Les Mikesell]

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.

-- 
  Les Mikesell
    lesmikesell(a)gmail.com

[Derek Martin]

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).

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

[Jay Moore]

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

[Robert Nichols]

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 .

-- 
Bob Nichols         Yes, "NOSPAM" is really part of my email address.

[Jay Moore]

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
}

[Les Mikesell]

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.

-- 
  Les Mikesell
    lesmikesell(a)gmail.com

[Robert Nichols]

Jay Moore wrote:
>             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. 
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.

-- 
Bob Nichols         Yes, "NOSPAM" is really part of my email address.

[Les Mikesell]

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.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. 
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).


-- 
  Les Mikesell
    lesmikesell(a)gmail.com

[Jay Moore]

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.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.
>  
>  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

[Les Mikesell]

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.

-- 
  Les Mikesell
    lesmikesell(a)gmail.com

[Tim]

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(a)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.

-- 
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.