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@xxxxxxx> 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".
> Looking
> 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@[ip-literal] addresses, but that behavior is
outside the standard.
john
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf