Also sprach Greg A. Woods
>[ On Wednesday, March 27, 2002 at 21:36:44 (-0500), Jeff Mcadams wrote: ]
>> Subject: Re: [Exim] Exim 4.02 new "feature"
>>
>> Man...considering that there are virtually no reasonable expectations
>> that a system can make about the structure of a Received header...I
>> don't see that as a significant drawback.
>
>Obviously you haven't tried to read the procmail scripts some people
>write! (I wish I hadn't either! :-)
>
>(anyone MTA implementor who can't make their program generate conforming
>received headers should go back to programming school too!)
>> *boggle* Say what?! Underscores or not...putting any stock in a
>> reported hostname for auditing or security purposes is suicide at
>> best.
>Huh? No, I was talking about the audit trail of of an e-mail message
>that was transmitted via SMTP over TCP/IP.
Again...if you put any stock in the HELO value of an SMTP exchange
(whether its stored in a Received: header, or in an application logfile,
or whatever) then you're incredibly naive.
>If an independent agent is to validate the path a message took
If an independent agent is to validate the path a message took then it
would be idiotic to expect the HELO parameter (as recorded in log files
and Received headers) to give any information of any value.
>then the log files on the servers it passed through are not sufficient
>alone, especially not if plain old SMTP was used over plain old TCP/IP.
>The received headers are what make the log records believable (and any
>IDENT records logged in the headers and the server logs are an extra
>confirmation) that everything in this fragile network of information
>actually hangs together and can be believed within reasonable limits.
And you cannot sanely put any significant value on Received headers
prior to the ones that your own mail server put into a message. I could
easily inject an original (ie, not forwarded from other mail servers)
into a mail server and add 15 of my own bogus Received headers into the
message. The only thing that you, as a mail server operator, can really
put any faith in being real is the Received header that *your* mail
server added. That Received header (that your mail server added) will
point you to the IP address of the sending system...beyond that...making
any assumption about the Received headers being valid is just asking for
trouble. Sure...its a nice sanity-check if Received headers (HELO
parameters) match with logs, but hardly indicative of any foul play if
they don't.
>You might not have had the pleasure of having to prove a message was
>transmitted over a given path and be able to provide corroborating
>evidence or at least pointers to it, but if ever you do then that's
>when you'll very much appreciate how this web of information fits
>together and just how important it is for all the hostnames to have
>been checked and validated and properly recorded along the way
I would never make any pretense of being able to say that a given
message took a given path...to do so is foolish. The best that you can
do is say, "This is where my servers received it from...if you want to
conclusively track the message back farther, go talk to them. This is
what the Received headers say...they may or may not bear any correlation
with reality."
>> Or just use the IP address of the connecting machine (which has to be
>> valid or no TCP connction can be established in the first place) and
>> be done.
>IP#s change over time.
*blink* And hostnames don't?
>If we were to all use just IP#s then we wouldn't be discussing what a
>valid hostname looks like now would we?
Wow...you are the master of taking things out of context, aren't you?
Again...I'm making *no* claims about the lack of utility of hostnames,
the DNS system, Envelope from's and to's, or any other headers that may
be in a mail message. This is *purely* about the utility of the
parameter to a HELO command in the SMTP exchange.
>If you're going to use a name then you have to make sure that name is
>correct and valid at the time it is used.
OK...if you want to validate hostnames in HELO's, feel free...but since
the parameter of the HELO is not practically used for anything, if I
don't validate it...it does no harm. My mail server (Exim) will accept
the message with no problem, if it forwards the message on to another
mail server, there will not be an underscore in the HELO parameter, its
that simple.
If you want to parse Received headers, and my Received header has an
invalid hostname in it...do whatever you want...trash the message,
whatever...worst case, the same thing will happen to the message as if
the originating mail server tried to send it to you directly without
passing through my system. Again, no harm done.
>You get no second chances in a two-layer naming system like we use with
>the DNS and IP addresses. The mapping of a name to an address is only
>valid for the TTL given in the DNS record you learned it from (and
>unfortunately sometimes not even that long!). You cannot still have
>your cake if you've aready eaten it.
But this is true whether there's an underscore in the HELO or not, and
as such is irrelevant to our discussion.
>If you're going to use the name
But that's the point...mail servers *don't* use the name in the HELO for
anything other than just stuffing it in the log and the Received
headers...if you're sane, you're also stuffing the IP address in there
with it, so the name is redundant at best.
>then you'd bloody well better get it right and you'd better use a name
>that fits even the narrowest definitions of what names are valid
>because if you don't then you will eventually be called to the carpet
>(i.e. your e-mail will eventually get rejected by someone being strict
>about what they accept and believe from the Big Bad Internet).
OK...let's see if we can get this straight here Greg.
You will not get a HELO message from our servers that have an underscore
in them, period.
Our servers will accept an underscore in the HELO from other mail
servers because it does no harm and helps interoperability.
If your mail server rejects mail that comes through our mail server
because there's an underscore in a hostname in the Received header that
our mail server added, then it would have rejected the message if the
originating mail server would have sent that message directly to your
mail server and the result ends up exactly the same.
Again, our accepting underscores in HELO's did not cause any harm
whatsoever, period. The issue really is just that simple.
>Planix, Inc. <woods@???>
Oh, BTW, mail.planix.com accepts underscores in HELO's.
--
Jeff McAdams Email: jeffm@???
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
