This decision raises a somewhat larger issue, namely whether deferring
to implementor desires is always the right thing to do. Compared to
implementers, there are many more users and system administrators. For
the reasons discussed earlier and alluded to below, they now lose in
having poorer error handling and more abuse. I thought standards
writers and implementer were supposed to serve end users (and maybe
the large number of people having to install and manage things), not
the other way around. Maybe this is another instance of the oft-
bemoaned absence of operators from the IETF discussion. End users seem
to be even more absent, even indirectly.
Henning
On Apr 15, 2008, at 7:15 PM, Douglas Otis wrote:
On Apr 14, 2008, at 7:33 PM, Tony Hansen wrote:
The SMTP implementations that have made the transition to support
IPv6 appear to already have done it in a way that supports AAAA
records for the implicit MX case. In some cases they are following
RFC 3974, and other cases they are just using getaddrinfo() and
letting it do the rest. Note that RFC 3974 itself was supposedly
"based on experience in deploying IPv6". At least one of these MTAs
is in common use around the network in the IPv4 world.
In essence, these implementations are following the RFC 821 and RFC
974 (sans WKS) rules of looking for address records. They've ignored
the A-only wording of RFC 2821 and are acting like we specify
currently in 2821bis-09.
In my queries I haven't yet found any IPv6-capable SMTP server that
doesn't do it.
I've seen examples of sites that are in regular use that mail would
break in an IPv6-only world if implicit MX to AAAA did not work.
From this viewpoint, running code wins.
Abusive running code wins as well. Indeed, many bad-actors will
appreciate not being limited to A or MX records, as specifically
specified in RFC 2821 discovery mechanisms. Whether the specifics of
this specification were in error is a separate issue, where endorsing
AAAA records as a valid discovery mechanism represents a substantial
change, and one likely to prove unsuccessful when more widely adopted
and then abused. The A resource record enabled a transition to MX
resource records. The necessity of the implied MX record is no longer
justifiable. Permitting A records as a means to discover SMTP servers
often generates a steady amount of abuse by bad-actors that use A
record only host-names as spoofed domains in their email-address.
To overcome what is destine to become an undesirable MX fall-back
mode, some have suggested bogus MX records could be published
instead. Bogus MX records would then become perhaps the _only_ means
to protect hosts not involved in the public reception of SMTP
messages. Much of the undesired traffic does not directly emanate
from clients controlled by bad-actors. Often, undesired traffic
results from attempts to validate oft spoofed email sources. The
level of this undesired traffic can be substantial.
I'm also swayed by the principle of "least surprise". Some of the
responses I've gotten have been along the lines of "Why's this a
question? Of course you do AAAA lookup". One person who had a site
set up with an IPv6-only connection and no MX record told me "I
wanted to forward my e-mail to an account on that machine. It worked
the first time, so I didn't see a need to change it." As mentioned
above, at least one of the IPv6-capable MTAs is in common use around
the network in the IPv4 world, and turning on IPv6 on those boxes
should not cause surprises.
Those wanting inbound SMTP on their IPv6 only hosts can routinely
include MX records in addition to their AAAA records. Keeping a
requirement to publish either A or MX records would alleviate the rest
of the world from seeking protection by publishing bogus MX records
for all hosts where inbound SMTP is not desired. High levels of abuse
often require public inbound receivers to specialize in defending
against the abusive traffic. The percentage of public SMTP servers
represent a shrinking minority of hosts that might benefit from a
convenience of not needing to publish MX records. However, to improve
both the performance of SMTP servers in general, and acceptance rates
of IPv6 only hosts, publishing MX records for an email domain is
likely to become increasingly critical. "Least surprise" is assured
by discovery methods that work on a large scale while also limiting
avenues for abuse. Having AAAA records imply MX resource records on a
large scale without rampant abuse would be astonishing.
Last of all, I'm swayed by the discussions around RFC 974 and the
DRUMS archive search around the question of what led to the wording
change in 2821bis saying explicitly to do A lookups. These indicate
that the intent of adding the A record description was to be
descriptive, not prescriptive nor proscriptive.
SMTP represents a great achievement. Much of this achievement has
occurred by minimizing administrative efforts needed to establish SMTP
services. These minimal administrative efforts now play a significant
role in fostering current levels of abuse afflicting SMTP.
Standardizing on AAAA as an MX fall-back moves SMTP and IPv6 in the
wrong direction. Sensitivity to abuse adopts a practice of "opt-in"
rather than "opt-out". AAAA as an MX fall-back may necessitate SMTP
IPv6 hosts the need to publish bogus MX records for the specific
purpose of "opting out".
So the bottom line is that I see sufficient support for including
AAAA lookups when implicit MX comes into play.
It seems the specification should attempt to differentiate what might
be achievable within private versus public server configurations.
It's been suggested that 2821bis revert back to either the implicit
MX description found in RFC 821 or RFC 974, although Glen Anderson
had some suggested improvements to that latter's description that do
make it clearer. Any of these three would satisfy this decision, and
I'll let John choose the wording he prefers.
While ensuring that the 'S' in SMTP upholds the concept of Simple,
avoiding greater levels of abuse will help further that goal. While
those that live and breath SMTP don't want to see any administrative
dependencies added, this costs hosts running unrelated protocols that
must then terminate a seemingly endless stream of SMTP related abuse.
The success of SMTP requires greater administrative care be taken. To
take this to the logical conclusion, the transition to IPv6 with a
reduction in SMTP related abuse would be further aided by deprecating
use of A records as an MX fall-back mechanism published in a follow-on
draft, where the current draft could warn of this possible change.
-Doug
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf