[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis

2008-03-30 20:54:27
I'm no longer going to comment on the mail aspects of this MX 
debate on the IETF list -- see the ietf-smtp list.  But there is 
an issue here with much broader implications...

--On Monday, March 31, 2008 9:36 AM +1000 Mark Andrews 
<Mark_Andrews(_at_)isc(_dot_)org> wrote:

      It's a natural back port of the SRV rules to MX.

              "SRV 0 0 ." indicates "no service".

Well, strictly speaking, it doesn't mean that, regardless of 
what the SRV specs say.   What is means is "this service is not 
advertised for this domain".  If a service is associated, as 
part of its protocol, with an established (not necessarily 
well-known) port, then the only way to determine that the 
service isn't offered is by attempting to connect to that port. 
If is isn't associated with a specific port, one may have a hard 
time trying to find the service, but the only way to know that 
is isn't being offered is scan ports looking for it its 
symptoms.   For good reason or bad, there are also all sorts of 
ways to communicate the location of a service and the port to 
use that have nothing to do with the DNS and DNS changes, 
restrictions, and records cannot affect them.  These are not 
special properties of SMTP, with or without MX records; they are 
properties of TCP.  If one wants to fix those problems, then TCP 
has to be changed to affirmatively return a "no service" message 
if an attempt is made to connect to a port on which no service 
is specifically listening.

      It was obvious 20+ years ago that MX processing was broken
      as there was no way to say "I don't want email".

First, it may have been obvious to you, but it wasn't obvious to 
many of us.   In the general case, it still isn't.  But you 
stated the situation exactly correctly.   "MX 0 ." means "I 
don't want email".   "SRV 0 0 ." doesn't really indicate "no 
service", it indicates "please do look for that service here".

      a the MX record, "MX 0 ." was the obvious solution.  The
      only reason I can see that it never went ahead was FUD.

While it is better than interpreting the lack of a bit in a WKS 
record as "no service", it is still nothing more than an attempt 
to use the DNS to say "please don't try a mail connection to 
this domain".  I think that is probably ok and would be happy to 
see a proposal carefully considered to see if consensus could be 
reached (as Frank points out, there was such a proposal but it 
quietly disappeared, no FUD campaign needed).  But I note that 
"please don't do X" is a solution to a different set of problems 
than a solution that would prevent someone who is predisposed to 
antisocial behavior from trying something.  Since bad guys can 
deduce addresses by scanning --and will certainly do so if we 
make it sufficiently hard for them to use the DNS-- this type of 
DNS change, it seems to me, would have little effect on the 
antisocial.   And, again, that isn't a statement about email 
because it applies with equal force to any other application 
service we have.

      It's so obvious that some MTA's already implement it.  Exim
      is the example I've been told about.

      The existing MX processing rules assume that *every* host
      wants to receive email.  The assumption has not been correct
      for 20+ years.

The existing A processing rules assume that *every* host wants 
to, or is at least able to, receive web connections, file 
transfer connections, SIP connections, telnet connections, 
Jabber connections, and, by the way, DNS connections.  Changing 
the MX rules won't change the assumption that every host 
supports email.  And most, it will make a statement of 
preference that mail connections won't be accepted more clear. 
And, viewed in that light, Exim's behavior represents a 
willingness to honor a preference... a willingness that, 
incidentally, can be bypassed by the simple expedient of giving 
it an address in literal form rather than one that is processed 
via the DNS.  Of course, Exim can, and often is, configured to 
reject mailbox(_at_)[ip-literal] addresses, but that behavior is 
outside the standard.


IETF mailing list