Also sprach Greg A. Woods
>> 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.
/me watches his argument zoom right over Greg's head.
The statement, as originally presented in the RFCs may have been made in
relation to protocol design, but the concept does apply equally well on
the level that we're dealing with.
Let me try to approach this idea this way. Outside of any context, I
say, "To be robust be liberal in what you accept, and conservative in
what you send." Now, without any surrounding context (including your
knowledge of the RFC's) is that advice to a protocol designer, or a
sysadmin? It can apply quite well to both.
>> 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.
Absolutely, and if you go back and re-read my previous message, you'll
see that I affirmed your right to only accept mail from mailers that
include the text "Greg Woods is a God" in the HELO if you want. Like I
said, though, I would hope you wouldn't expect to get much mail if you
did that. :)
>(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.
I'm totally with you on this part.
>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.
Suing over a $29.95 account is absurd, I'll definitely grant you that.
>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!)
Heh...we have a concept that we talk about here at IgLou, that the
amount you pay is proportional to your right to complain about your
service. If you get a free (or deeply discounted) account, "deal." :)
>> 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,
Well...similarly to what you said above (where you said I couldn't make
that decision for anyone else)...that implementor can really do whatever
the heck they like...whether they understand the implications of what
they're doing or not...just don't come whining to me when what you've
done has backfired.
>(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.
I think we mostly agree here.
>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).
As you said "default"...I'll certainly agree with this, though I think
we'll disagree about what the limits should be of what should be allowed
by explicit action of the admin. Fortunately, we don't have to work
with each other in admin'ing a mail server, so we can handle it
differently and still be OK. Our mail servers will even be ok sending
mail between each other because we both have mail servers that conform
to the RFC's on the sending side of things (we don't use "_" in HELO in
our outgoing connections).
>> 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.
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.
>> 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.
*boggle* Say what?! Underscores or not...putting any stock in a
reported hostname for auditing or security purposes is suicide at best.
>(Of course to really make sure the name is correct and usable
>in an audit trail you have to validate the DNS...
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.
--
Jeff McAdams Email: jeffm@???
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
