[Top] [All Lists]

RE: Last Call: draft-klensin-rfc2821bis

2008-03-27 08:51:52
You are completely incorrect in describing MX records as no more than an 
optimization. The MX record defines the mail SERVICE. An A or AAAA record 
defines a HOST.
Nor am I rewriting history here, the early RFCs that describe the emergence of 
the mail service and the DNS make it very clear that the operational needs of 
email were not fully understood at the start of the process. That is why it was 
called research.
The MX record was very clearly introduced in recognition of the fact that 
deployment of the DNS made possible better options than had been possible with 
the hosts file.
And begging the question is a logical fallacy in which the conclusion is 
assumed in the premise, petition principii.

From: Tony Hain [mailto:alh-ietf(_at_)tndh(_dot_)net]
Sent: Wed 26/03/2008 6:59 PM
To: Hallam-Baker, Phillip; ietf(_at_)ietf(_dot_)org
Subject: RE: Last Call: draft-klensin-rfc2821bis

Your arguments make no sense. Any service that has an MX creates absolutely
no cost, and the fallback to AAAA only makes one last attempt to deliver the
mail before giving up. Trying to force the recipient MTA to publish an MX to
avoid delivery failure on the sending MTA is useless, and in no way belongs
in a standard document. MX records are an operational optimization, nothing
more. The function of mail delivery is between IPv4/IPv6 endpoints, and how
those endpoints find each other is orthogonal to the actual service of mail
delivery. Having the document state a prioritization between 2 of the
possible methods is pushing the edge already, but worth allowing because
there should be consistent interpretation between domains that don't have a
prior agreement.

You should also stop trying to rewrite history by claiming that something
was 'not understood at the time'. While you may wish things were more
tightly enforced, pragmatics will always win out, which also means that no
matter what the IETF says people will do whatever it takes to deliver the
mail. If you don't want mail delivered to any machine except those with an
MX, then don't listen on the port for all the others.

This actually begs the question, how would publication or not of an MX have
any impact on a spam-bot network? It is not like the service provider mail
servers are trying to look up bot members to send spam to. If the service
provider mail servers are doing MX lookups as some sort of verification
step, it is trivial for a spammer to create a bunch of MX records to bypass
that lame effort.


From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Hallam-Baker, Phillip
Sent: Wednesday, March 26, 2008 2:26 PM
To: alh-ietf(_at_)tndh(_dot_)net; ietf(_at_)ietf(_dot_)org
Subject: RE: Last Call: draft-klensin-rfc2821bis

I don't undestand the reasoning here.
My understanding is that we implicitly deprecated receivers relying on
fallback to A in 2821. Section 5 makes it clear that you look for MX first
and that MX takes priority.
It is thus not compliant to look at AAAA records today and I see no reason
to change this in the future. Instead any 2821Bis should do the job of a bis
and deprecate reliance on A fallback, but not support for it. suggesting
that people write a BCP to deprecate a protocol feature instead of a bis
seems backwards to me.
Mail is a service lookup, not a host name lookup. Support for use of
fallback to IPv4 host name lookup is a historical accident due to the fact
that the distinction was not understood at the time. We do not require IPv6
host name fallback, IPv6 host name fallback has a significant cost that will
have immediate impact on every mail service lookup that is compliant.

IPv6 should use the service resolution lookup.
We should prohibit fallback to AAAA outright and deprecate configurations
that rely on A.
From: ietf-bounces(_at_)ietf(_dot_)org on behalf of Tony Hain
Sent: Wed 26/03/2008 3:14 PM
To: ietf(_at_)ietf(_dot_)org
Subject: RE: Last Call: draft-klensin-rfc2821bis
John Levine wrote:
Not to be cynical or anything, but regardless of what we decree, I
think it's vanishingly unlikely that many systems on the public
Internet* will accept mail from a domain with only an AAAA record.

I think it's vanishing unlikely that email will be useful at all, if
filter writers keep trashing mail based on such dubious criteria.

Not to reignite the usual spam argument, but it is (unfortunately in
case) not 1988 or even 1998 any more.  When upwards of 90% of all mail
spam, keeping mail usable is at least as dependent on limiting the spam
that shows up in people's mailboxes as delivering the trickle of good

Real life spam filters use metrics and tune to the actual behavior of
mailers.  If most of the mail that comes from domains with AAAA and no
is spam, they'll tune for that, and it won't be a mistake.  For the
forseeable future, most such mail will be from zombies, and it'll all

This document is not the place to fight spam. If you want a BCP to deprecate
the fall-back, then write one. Until all the implementations remove
fall-back to A, the correct behavior is to also fall-back to AAAA. People
(particularly the apps dev & support communities) are having a hard enough
time getting their heads around even thinking about IPv6 that making your
proposed procedural change is insane. Whatever reasons people have for not
implementing MX will not change just because they are deploying IPv6.

The current text is just fine the way it is.


IETF mailing list

IETF mailing list