headers
William Allen Simpson | 28 Jun 2003 00:47

daily (& security) mail not delivered

Apparently, for the past couple of months, the default install stopped 
sending mail to root <at> localhost.  (I didn't notice until I did a clean 
install of current recently, having stopped at Oct version.)

Investigating, I found 2 obvious reasons (there may be more): 
 * the mail is queued in /var/spool/clientmqueue/ and never delivered,
   due to insufficiently tested changes to sendmail in late March.
 * the mail is attempting to deliver to "localhost.dom.ain.", instead 
   of "localhost."

 (A) PR install/21998

     Obviously, failing to process the daily and security mail is a 
     security flaw.  Also, a pretty bad software bug.

     My proposed solution is to abandon sendmail, and use postfix as 
     the default install.  Perry Metzger proposed a single line fix. 
     This has been controversial. 

     Andrew Brown has suggested a somewhat larger patch for the
     sendmail install, instead. 

     Anyway, I'm thinking my approach would be a marked change of 
     policy, timely for a 2.0 release, that warrants wide discussion.

 (B) PR install/21999

     My proposed solution was to add the "localhost.dom.ain" line to 
     /etc/hosts.  I even found the spot where an obsolete duplicate 
     localhost line could be replaced cleanly.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Brown | 28 Jun 2003 03:23

Re: daily (& security) mail not delivered

>Apparently, for the past couple of months, the default install stopped 
>sending mail to root <at> localhost.  (I didn't notice until I did a clean 
>install of current recently, having stopped at Oct version.)
>
>Investigating, I found 2 obvious reasons (there may be more): 
> * the mail is queued in /var/spool/clientmqueue/ and never delivered,
>   due to insufficiently tested changes to sendmail in late March.

at least it gets queued and not dropped.

> * the mail is attempting to deliver to "localhost.dom.ain.", instead 
>   of "localhost."

sendmail likes to fully qualify things, especially for smtp
transactions.  if i "echo test | mail root", my fully qualified
hostname gets added.  if i "echo test | mail root <at> localhost", the
localhost piece gets removed and replaced with my fully qualified
hostname.  it sounds to me like your machine wasn't completely
configured.  i've seen problems like this before, and they're
relatively easy to fix.

> (A) PR install/21998
>
>     Obviously, failing to process the daily and security mail is a 
>     security flaw.  Also, a pretty bad software bug.

they're queued.  you can get them later.

>     My proposed solution is to abandon sendmail, and use postfix as 
>     the default install.  Perry Metzger proposed a single line fix.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Brown | 28 Jun 2003 03:33

Re: daily (& security) mail not delivered

>>     Andrew Brown has suggested a somewhat larger patch for the
>>     sendmail install, instead. 
>...
>so you have two choices.  the first is the one i detailed to you
>(create your own sendmail.mc from the netbsd-proto.mc, tweak it, build
>the corresponding cf, and install it), though you could just as easily
>have tweaked /etc/rc.conf in the manner described above.  either way,
>you'd have to start the sendmail smtp daemon.
>
>on the postfix side, if you want, you'd still have to tweak the config
>file, enable it in /etc/rc.conf, and start it.  you'd also have to
>tweak another file, and select it via /etc/mailer.conf.  it's about
>the same amount of work either way, imho.
>
>either way there's configuration to be done.  pick your poison.  :)

furthermore, these two choices are the same because:

both sendmail and postfix require you to enable them in /etc/rc.conf
and start them.

both sendmail and postfix require you to configure them to disable the
globally visible smtp service.  they will also both be happier if you
have done a bit more configuration of the system before you start
them.

both sendmail and postfix will queue mail entered locally and leave it
there if the main process is not running.

however, these two choices are different because:
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Allen Simpson | 28 Jun 2003 04:44

Re: daily (& security) mail not delivered

Andrew Brown wrote:
> 
> sendmail likes to fully qualify things, especially for smtp
> transactions.  if i "echo test | mail root", my fully qualified
> hostname gets added.  if i "echo test | mail root <at> localhost", the
> localhost piece gets removed and replaced with my fully qualified
> hostname.  it sounds to me like your machine wasn't completely
> configured.  

You mean "sounds to me like your machine wasn't completely configured 
BY SYSINST."  Yes, that's why I'm raising the issues.

> i've seen problems like this before, and they're
> relatively easy to fix.
> 
Great!

> > (A) PR install/21998
> >
> >     Obviously, failing to process the daily and security mail is a
> >     security flaw.  Also, a pretty bad software bug.
> 
> they're queued.  you can get them later.
> 
Actually, those from only a few days ago are already gone, and the 
message saying each was discarded is in the queue -- waiting to be 
discarded.

> >     My proposed solution is to abandon sendmail, and use postfix as
> >     the default install.  Perry Metzger proposed a single line fix.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Brown | 28 Jun 2003 05:50

Re: daily (& security) mail not delivered

>> sendmail likes to fully qualify things, especially for smtp
>> transactions.  if i "echo test | mail root", my fully qualified
>> hostname gets added.  if i "echo test | mail root <at> localhost", the
>> localhost piece gets removed and replaced with my fully qualified
>> hostname.  it sounds to me like your machine wasn't completely
>> configured.  
>
>You mean "sounds to me like your machine wasn't completely configured 
>BY SYSINST."  Yes, that's why I'm raising the issues.

sysinst isn't something i know all that much about.  i do, however,
know how i want my machines to behave, so i check all sorts of things
and tweak stuff manually all the time.  as to what sysinst does, or
how much it should or should not, i can't say.

>> > (A) PR install/21998
>> >
>> >     Obviously, failing to process the daily and security mail is a
>> >     security flaw.  Also, a pretty bad software bug.
>> 
>> they're queued.  you can get them later.
> 
>Actually, those from only a few days ago are already gone, and the 
>message saying each was discarded is in the queue -- waiting to be 
>discarded.

if they're gone, that's another matter.  there's *no* reason for
something to leave the clientmqueue unless it gets properly passed to
an smtp listener on the loopback interface, period.
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Allen Simpson | 28 Jun 2003 07:13

Re: daily (& security) mail not delivered

Andrew Brown wrote:
> 
> >You mean "sounds to me like your machine wasn't completely configured
> >BY SYSINST."  Yes, that's why I'm raising the issues.
> 
> sysinst isn't something i know all that much about.  i do, however,
> know how i want my machines to behave, so i check all sorts of things
> and tweak stuff manually all the time.  as to what sysinst does, or
> how much it should or should not, i can't say.
> 
<rant>
When I first tried to come back from OpenBSD last Sept with 1.6, sysinst 
didn't match its documentation.  I wrote up a long list of problems, and 
some of them were fixed.

Now, I find that nobody seems to have noticed that sysinst has been 
improperly configuring systems for months....  Yet, NetBSD has a list 
dedicated to working on the installer?

OpenBSD may have its problems, but the installer got better with every 
release.  People actually use it!  It matches the documentation, and 
the documentation is printed in every CD jacket.  Jeez o' Pete....
</rant>

> >> > (A) PR install/21998
> >> >
> so you also want sysinst to do minor mta configuration and enable the
> mta?  i'm not trying to be argumentative here, just trying to pin down
> the points of contention.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
matthew green | 28 Jun 2003 09:37
Picon
Favicon

re: daily (& security) mail not delivered


   >> sendmail likes to fully qualify things, especially for smtp
   >> transactions.  if i "echo test | mail root", my fully qualified
   >> hostname gets added.  if i "echo test | mail root <at> localhost", the
   >> localhost piece gets removed and replaced with my fully qualified
   >> hostname.  it sounds to me like your machine wasn't completely
   >> configured.  
   >
   >You mean "sounds to me like your machine wasn't completely configured 
   >BY SYSINST."  Yes, that's why I'm raising the issues.

   sysinst isn't something i know all that much about.  i do, however,
   know how i want my machines to behave, so i check all sorts of things
   and tweak stuff manually all the time.  as to what sysinst does, or
   how much it should or should not, i can't say.

the problem is that /etc/daily, /etc/security, etc., used to all
"just work" for a default install.  since sendmail was upgraded
a while ago that hasn't been the case.  something needs to be
done by hand to make this work...

ie, you broke a feature of netbsd ... do you not consider that
to be a problem?

.mrg.
Permalink | Reply | 0 comments |
headers
Alan Barrett | 28 Jun 2003 12:54
Gravatar

Re: daily (& security) mail not delivered

On Fri, 27 Jun 2003, William Allen Simpson wrote:
>      An alternative solution was proposed that we find all the bad 
>      libraries, applications, and scripts, and fix them to always use 
>      "localhost." (note trailing dot).

Could you post a pointer to this proposal?  I have not seen any such
proposal, though I have seen (and refuted) a message in which you
attributed something like that to me.

--apb (Alan Barrett)
Permalink | Reply | 0 comments |
headers
Alan Barrett | 28 Jun 2003 13:05
Gravatar

Re: daily (& security) mail not delivered

On Fri, 27 Jun 2003, William Allen Simpson wrote:
> > i think you're overinterpreting rfc1912.  i don't get the sense that
> > they intended for you to literally use "localhost.dom.ain" as a
> > hostname.
> > 
> Page 14:
>       Translating 127.0.0.1 into "localhost.dom.ain" can cause some
>       software to connect back to the loopback interface when it didn't
>       want to because "localhost" is not equal to "localhost.dom.ain".
> 
> Seems that "localhost.dom.ain" is not the same as 127.0.0.1 to me?!?!
> (Did I mention that I was in the WG discussion for the earlier drafts?)

I believe that that part of RFC 1912 is referring to software that
starts with the name "localhost", converts that to the address 127.0.0.1,
converst that back to the name "localhost.dom.ain", and then gets confused
when a string comparison shows taht "localhost" != "localhost.dom.ain".

--apb (Alan Barrett)
Permalink | Reply | 0 comments |
headers
Alan Barrett | 28 Jun 2003 13:18
Gravatar

Re: daily (& security) mail not delivered

On Fri, 27 Jun 2003, Andrew Brown wrote:
> particularly if "localhost.dom.ain" isn't in the dns.  it really ought
> to be in the dns.

No, there is no need for localhost.dom.ain to be in the DNS.
There is also no need for it to be in /etc/hosts.

In my experience, everything work just fine if "localhost. A 127.0.0.1"
is in the DNS, and "127.0.0.1 localhost" is in /etc/hosts, and
if "localhost.${domain}" does not appear anywhere at all.  When
applications try to make network connections to "localhost" or send
mail to user <at> localhost, then there might or might not be a short delay
while a DNS or /etc/hosts lookup for localhost.${domain} is attempted
and returns a "no such host" status, but then the relevant libraries
will immediately look up plain "localhost", that will will succeed, and
everything works.

--apb (Alan Barrett)
Permalink | Reply | 0 comments |

Gmane