[ On Wednesday, November 21, 2001 at 12:16:57 (+0000), Jonnie wrote: ]
> Subject: Re: [Exim] double check DNS
>
> For some reason RFC 2821 holds back from saying 'MUST'.
> I guess there may be some elbow room intended for some wierd
> situations - I don't think they just throw these RFCs together.
Well, no, RFCs are not just "thrown together". However they're not pure
technical documents either -- just as with any proper engineering effort
they reflect the biases of the engineers who write them and their
understanding of the sociological and political climate of the community
to which they are expected to serve in.
RFC 1123 is, for the most part, an attempt to strike a happy balance
between the technical and political needs of the Internet community
circa 1989. Back then the DNS was still a relatively new thing, and
requiring deep and exacting involvment in the DNS of all members of the
Internet community at that time was impossible (or rather would have
been counter productive).
> I suppose a 'bad' client could point to it as justification.
No, you've got it completely backwards.
A 'bad' client has no justification at all (at least not under RFC
1123). All clients "MUST" provide their proper canonical hostnames in
the SMTP greeting. There are no if's, and's, but's, or excuses (except
for the unwritten, until RFC 2821, agreement that a literal
representation of the client's source IP address is also acceptable,
though personally I also require a valid PTR in that case).
The reason servers are not supposed to validate this name and reject
connections if it is invalid is because to do so at the time RFC 1123
was written would have dramatically affected not only a vast number of
existing SMTP clients at that time, but also the political viability of
RFC 1123 itself (and of its authors and editor!).
RFCs are almost always written to be guides in leading the majority of
implementers along the path of improvement and modernisation. Even if
they are technically perfect they can only succeed if implementors pay
attention to their details. The self contradictory nature of RFC 1123
section 5.2.5 can be seen as both a guide for the future (from the
perspective of 1989), and as a compromise to the situation (as of 1989).
As someone who was on the periphery of the process since before 1989,
and who's been knowingly ignoring the compromise part of that section
for several years now, I can assure you that the situtation today is
vastly different than it was back then in 1989.
> Incidentally, 2821 is clearly intended to replace
> 1123 (as far as mail transport goes) - but that would be a
> standardization issue (?).
That's not the way the process will likely pan out. Yes, RFC 1123 is
sadly in need of updating. However from what I undersand very little of
what it says of SMTP needs to be updated in order to RFC 2821 to fully
replace RFC 0821 as the current "standard" for SMTP. However at this
point (i.e. as of 11/20/2001) RFC 2821 is still only a "proposed
standard". RFC 0821 is still listed with the status of "standard" even
though it has been declared "obsoleted" by RFC 2821. Note too that RFC
1123 is simply a clarification of and supplement to which parts and
options of other RFCs are required in order that a host be considered
fully interoperable on the Internet.
> I'm not suggesting that there's any explicit support in any RFC
> for a client NOT giving its canonical hostname (or IP literal) in HELO.
Indeed there is not, as I've discussed above.
> It's just that there's scope for a really nasty "is / isn't rfc-legal"
> argument if you turn down transactions just because you don't like the
> HELO argument.
Luckily there's no valid RFC-based argument against implementing a
policy by validating the client name against the DNS because of two very
key points: 1) all clients are required to utter a valid greeting name
regardless of what the server they're talking to might do with it; and
2) servers are in fact allowed to reject transactions based on any
criteria whatsoever since even such basic security and any kind of
service agreements have nothing whatsoever to do with network protocol
interoperability. I'm not sure who said it first, but I now at least
Paul Vixie and myself (and no doubt others) have at one time or another
said that the so-called "robustness principle" has no place in deciding
policy for any given host or site.
My SMTP server is in fact perfectly capable of interoperating with any
client that does nothing else wrong other than to not utter its name
correctly in the SMTP greeting, but there CAN NOT BE any valid
requirement that I allow any and all clients to send e-mail to my
server, and if I choose to decide not to allow my server to interoperate
with clients that do not utter their names correctly then that is my
policy decision and nobody can say otherwise for any reason, ever.
In other words the second paragraph of RFC 1123 5.2.5 is irrelevant and
completely meaningless and toothless. It is a guide for the times circa
1989, and nothing more.
> Also, I can't see how any policy based on this data
> couldn't be better realised in other ways.
No, unfortunately it is not possible to better realise such a policy in
any other way, and especially not in the way suggested in the rationale
for RFC 1123 section 5.2.5. Most users of e-mail today, and sadly even
many postmasters of SMTP servers today, cannot read and understand
standard e-mail headers in full (especially not "received:" headers).
Some users cannot even see the full message headers when they read their
e-mail. Furthermore it's far to late to do anything about a broken
client if you first accept any message from it, especially if that
client is being run by a spammer and may even be purposefully broken due
to either the spammer's fears, or his/her ego, or even his/her
misundertanding of what this name means in the context of SMTP.
> Exim, which is a very sensible piece of software, has helo_verify
> unset by default, but of course, it's there if you MUST :-)
Any non-spammer insisting on voilating RFC 1123 5.2.5 and trying to use
the second paragraph as their justification for doing so has no argument
and no valid justification whatsoever. Whether I or anyone else turning
on helo_verify or its equivalent in some other mailer will allow such a
person an exception to our policy is a matter of reaching a mutual
agreement and has nothing whatsoever to do with SMTP protocol
interoperability. In other words such a person does not even have the
support of their peers on this matter, let alone any IETF document.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@???> <woods@???>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
