Sorry for going back a couple of months, but I'm working on an MTA-specific RFC and this caught my attention.
> -----Original Message-----
> From: exim-users-bounces@??? [mailto:exim-users-bounces@exim.org] On Behalf Of W B Hacker
> Sent: Friday, November 19, 2010 3:34 AM
> To: exim users
> Subject: Re: [exim] Rejecting messages with no "To:" or "Cc:" field in
> the headers
>
> > Perhaps it really is time for a SMTP RFC stating that:
> >
> > (1) HELO / EHLO must resolve to the IP address of the sending server;
>
> The RFCs' HAVE said that since 'day one' - about twenty years now.
That's actually not true as far as I can tell. RFC821 (1982) says the HELO parameter (it predates EHLO) has to be the "official" name, but it doesn't say anything about querying the DNS to see if it matches anything specific. That is, the RFC provides no mechanism for confirming that the provided name is the "official" name (whatever that means).
RFC2821 (2001) does a better job, but still not what you're looking for. It says the HELO parameter has to be the fully-qualified domain name of the sending machine. But it fails to define that as well; in particular, just because I don't have reverse DNS set up for my mail server doesn't mean its fully-qualified domain name isn't "foo.bar".
RFC5321 (2008) didn't improve on this any.
> > (2) The sending server (MTA) must have a resolving host name.
>
> The RFC's HAVE said that also and for even longer. Predates smtp, IIRC.
Same; the RFCs don't say the name has to resolve, only that it has to be "official" or "fully-qualified". There is no requirement established to verify it against the DNS, especially since there are SMTP implementations where that doesn't make any sense (e.g. a pipe to your MTA, where TCP is not used). That's a receiver-side implementation choice.
> Mind - an 'IP Literal' is OK instead of a domain if not 'public facing'.
It's OK in any case.
> The *problem* is that smtp RFC's - (Hell ALL RFC's!) rely on a mesh of many.
> many *other* RFC's to establish the overall networking environment.
That's true of any modular system, or any system in which there are various applications providing related yet disjoint functions. This isn't a problem with the RFCs specifically.
> And those two particular points are not always so obvious in any one given
> smtp-relevant RFC. The other 'needful' ones are not even always
> referenced.
If there are such lapses that make sense to add, you might want to suggest it to the IETF.
There is an effort within the IETF to create a place where one can go to get a list, or even a diagram, of all the RFCs that cover a given topic area. I'd suggest you get involved in that effort if you think this would be a benefit.
> But dig deep, and find that ...
>
> ANY IP-using device offering a public service is supposed to have at least a PTR
> RR. And that requires a registered <domain>.<tld>. And that leads to a
> responsible-party-of-record. All that is in 'other-than smtp' RFC's.
> DNS-relevant, mostly.
Can you cite the ones where you found these facts? I don't remember any of that in any of the ones I've read, but I certainly haven't read them all.
> But smtp just happens to be one of the services where it really *matters* that
> an IP ALSO resolves, not to a 'generic' adsl.xx.xx.xx.xx.<domain>.<tld>
> but to an FQDN that can be 'associated' with a mail server in DNS.
There was an RFC draft put forward by the DNS operations working group inside the IETF that specifically discouraged people from trying to use A/PTR matching as an authentication mechanism. It never made it to published RFC status for various attrition-like reasons, but the material in there seemed to be well-founded and I expect we'll see it again.
> Problem there is that it is permissable to assign multiple
> <domain>.<tld> to one
> IP, and the critter making the first DNS call may not be able to parse a
> multiple return that is not in the same order each go. Or gets back only ONE of
> the several entries each go.
That's an implementation fault, not a fault in the specifications.
> RFC's for smtp *and applicable relatives* - applied as written long ago,
> insisting on HELO FQDN match, valid PTR RR and MX or A record, etc - even
> without strict HELo tests, usingf basically Exim's rDNS will stop nearly all
> zombies and botnets cold.
If there's consensus to push this toward a published document, I'd say your best bet is to try to take this work to the IETF either as an Informational document or as a Best Current Practices document. I have strong doubts that such a proposal could become a Standards Track document because it breaks back-compatibility in some pretty heavy-duty ways. That's not to say such measures aren't justified, just how the IETF tends to work based on my experience.
> With decent DNS entries assured, remaining 'now made visible' bad- actors can
> then be ID'ed. And scalled to account. Unless one lives in the USA, where
> Congress sold the mass-marketeers a (You too) 'CAN Spam act' for some
> serious money.
I don't think we can assert that bad actors can be reliably identified just because the DNS looks right. And with IPv6 gradually becoming a reality, I don't think we want to rely on IP addresses at all anyway.
> All the spf, DK, DKIM, yadda, yadda, is mere frosting on a cake that wasn't
> broke in the FIRST place ... if only the players stuck to the rules.
I think this understates the value of those mechanisms. They add a domain name to a message in a way that can be trusted in at least some minimal way, and that's a domain name that can be meaningfully evaluated. I'm not sure we've ever had that before.
When we see home DSL/cable providers giving out a /64 to each of their residential customers, I don't even want to think about using IP addresses and the DNS to do much of anything.
-MSK
