[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis

2008-03-30 21:53:34

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". 

        The lack of a SRV RRset means that.  

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. 

        "SRV 0 0 ." is a affirmative statement saying there is no
        service for this domain.  There may well still be something
        listening on the standard port processing transactions for
        another domain.

        You have similar today with MX records where host A can be
        handling all email directed to domain B and host B is
        handling all email directed to domain A.

        SRV support was NOT grandfathered in for existing protocols
        to avoid the well known port problem.

        The default was for NEW protocols that decided to use SRV
        records.  SRV lookup is not optional in these cases.

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".

        "SRV 0 0 <hostname>" means look for that service here.
        "." is not a valid hostname.
    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).

        The was FUD about the roots being overwhelmed by A lookups.
        That FUD was raised again the moment this was resuggested.

 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.

        I'm not really worried about anti-social behaviour.  I want
        good behaviour for real users that send email to hosts that
        don't have SMTP servers turned on.  1 week timeouts is not
        good behaviour.

    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.

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews(_at_)isc(_dot_)org