Also sprach Greg A. Woods
>[ On Wednesday, March 27, 2002 at 11:47:56 (-0500), Jeff Mcadams wrote: ]
>> On yet another hand, though (three hands?), standards are all about
>> supporting interoperability. Thus the "Be liberal in what you
>> accept, and conservative in what you send" concept. Allowing
>> underscores enhances interoperability in almost all cases, and given
>> that the HELO hostname is really (practically) not used for anything,
>> then accepting underscores really does no practical harm.
>That's the most mis-understood and most frequently mis-applied
>"concept" in the entire history of the Internet. That's advice for
>protocol designers, not for sysadmins!
On the contrary. You just don't *want* to apply it to sysadmin'ing.
The advice is still sound. The ideas that you run into protocol design
are largely the same ideas that you run into sysadmin'ing. The idea
that you are trying to build something that interoperates with something
that you may or may not have control over means that in order to achieve
interoperability, you may have to tolerate the other end doing something
differently from how you would do it. The advice/concept works equally
well on that level.
Does that concept justify breaking the RFC/standard (accepting
underscores in hostnames)? That's a good question, and one that each
implementor will have to decide for themself.
>The problem with underscores in hostnames has to do with the fact that
>by allowing them you are actually hindering interoperability.
Nonsense! The parameter to HELO is not needed for processing mail
messages transmitted in the session...so allowing underscores in the
hostname transmitted as the HELO harms interoperability exactly how? It
doesn't.
Please keep in mind that I'm not talking about allowing underscores in
domain parts (anything to the right of "@")...that's a whole different
story. The HELO parameter is local to the exchange only...probably gets
logged into a Received header and/or logfile, but otherwise is not used
in the process of delivering the actual message.
Should systems that have underscores in their hostnames change them to
be compliant? Absolutely, but accepting the underscores in HELO does no
harm to the interoperability of email.
>There are still many hosts which interact with Internet e-mail and
>which cannot handle underscores in hostnames.
And I would have no problem with them generating a 5xx response on a
HELO with an underscore. Indeed, I don't have a problem with a site
generating a 5xx on a HELO with an underscore whether it would cause
that site problems or not. Shoot...if you want your MTA to generate a
5xx if the client doesn't include the text "Greg Woods is a God." in its
HELO, that's perfectly fine by me...its your system...I just hope you
wouldn't expect to actually receive much email that way. :)
>By allowing underscores at the beginning you may allow an e-mail to be
>generated and transmitted which cannot ultimately be received at its
>final destination.
Let's say that I accept an email from a client system that uses an
underscore in its HELO, and I relay it on (legitimate relay, of course
;) to a destination that can't handle underscores in hostnames. My
connection to that other site will *not* use an underscore in the HELO,
because my system is configured to use a proper hostname...no problem.
Let's say, worst case, that the ultimate destination does something
bizarre like parse the contents of the Received header that I added
where I included the hostname from the originating system that had the
underscore, and it gives me a 5xx response because it sees that
underscore in the Received header (see how much of a stretch this is
getting to be already?). So, I can bounce that message back to the
sender (since I'm not advocating relaxing restrictions on MAIL FROM:'s)
just like any of a number of delivery errors would do.
Again...HELO parameters aren't actually needed to actually deliver
mail...accepting invalid hostnames for them doesn't harm
interoperability. The only thing you gain is that warm fuzzy feeling
that you're strictly adhering to the protocol specs. That's certainly
nice and all, but unfortunately, that doesn't put food on the table. :/
>(indeed the BIND-9 implementors having turned their backs on this issue
>are not helping much either)
That is unfortunate. :/ That's the ideal place to curb the use of
invalid hostnames. I've always been a tad bit frustrated with BIND's
hit and miss enforcement of standards. They seem to be very strict
about their enforcement of some things (some of the stuff in its file
formats, for example), while other things they just toss to the wind
(such as our hostname character restrictions that we're dealing with
here).
--
Jeff McAdams Email: jeffm@???
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
