[ On Wednesday, March 27, 2002 at 16:14:11 (-0500), Jeff Mcadams wrote: ]
> Subject: Re: [Exim] Exim 4.02 new "feature"
>
> Also sprach Greg A. Woods
> >
> > 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.
What the heck are you talking about? The so called "Robustness
Principle" espoused in RFC 1123 is explicitly advice to protocol
designers and those implementers of the protocols referenced. It is
explictly NOT advice for sysadmins. Even a causual reader of RFC 1123
section 1.2.2 should learn that much from it.
Until and unless you have a full and deep and wide understanding of the
implications inherent in the specified limits given by these guidelines
as they will apply across all the feasible implementations of these
protocols you'd do well not to throw that advice around out of context.
> 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.
You can be liberal in what you accept from the Big Bad Internet, but you
must not even try to make that decision for anyone else.
(As context for what the gentle reader might percieve my attitude to be,
let me just say that I've have more than enough from stupid lame idiot
users who insist that their e-mail must get through, whether they're on
the receiving end or not, regardless of anything and everything else.
Just today one of my clients had a customer threaten to sue them over a
stupid $29.95/month account just because someone was not able to send
e-mail to them. Guess what -- it turned out it was because their
correspondent was using a mail server with an underscore in its name --
and even worse it was only within the mailer's config, not even in the
DNS! Let the idiots try to run their own mail server -- meanwhile
they'd damn well better adjust their expections for discount ISP accounts!)
> 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.
If, and only if, a local postmaster understands all the possible
implications of straying outside the realm of the documented standards,
(which were, for the most part, designed explicitly to facilitate
interoperability), then that postmaster may do whatever the heck he or
she wants with his or her own mailer. However they should not be
surprised if suddenly some less obvious implication of their actions
comes home to roost in their nest.
By default however any implementation of a program providing a service
"advertised" to the Big Bad Internet should default to holding its
clients within acceptable limits (while at the same time allowing for
variations within those limits). This goes double for any type of
service like SMTP where the data handled may be re-transmitted in ways
that are not under the control of the server in question.
> >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.
Well, excuse me, but you just don't know, now do you. That parameter is
included in a header in the message and it's passed on to other programs
that may wish to parse it. If your mailer accepts garbage for that
parameter then it's violating the very reasonable expectations of of
those programs. There are reasonable limits placed on protocol
definitons even within the "robustness principle" in order to create
reasonable expectations of what an implementation at ay other level must
deal with.
> 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.
You can't just look at something like the HELO/EHLO parameter in
isolation -- you must look at it within the much larger context of all
the systems and layers that it may eventually touch. That name is the
way an audit trail is created. It's the only one place where all
servers involved in the message transmitted and is the only way server
logs can be corroborated. If you allow that name to stray out of spec
then you destroy that audit trail. (Of course to really make sure the
name is correct and usable in an audit trail you have to validate the
DNS in the same way TCP Wrappers "paranoid" check does, or the similar
checks done by other daemons and servers, and reject it if there's any
discrepancy at the DNS level, regardless of whether you also require it
to match the source address or not (just so long as you do all the other
steps specified in the rationale for RFC 1123 #5.2.5).
Allowing underscores in the HELO name is a very slipery slope I would
rather never slide down. Once the protocol designers have finally
decided on how we're going to achieve fully internationalised DNS names
then I'll be one of the first to encourage the adoption of such new
"limits" to the allowable hostnames used in protocols like SMTP,
regardless of whether they include underscores or not!
> 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).
I have to agree with you 101% there! ;-)
--
Greg A. Woods
+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
