On Mar 27, 2008, at 8:31 PM, Keith Moore wrote:
David Morris wrote:
Perhaps you could help us out and share a reference to
documentation of such problems. I for one have not personally
observed any problems related to using the A record to locate a
mail server when there is no MX.
part of the problem is that most hosts don't wish to receive mail
but there is no way to indicate this to a mailer that is trying to
deliver mail to them.
Agreed. Although MX records provide a discovery method for SMTP
services, fall-back to A records prevents an assertion of no SMTP
services when A records exist at the domain.
if the host has an A record, under the current specifications, a
mailer that gets a message (presumably spam) with a recipient
address at that domain is expected to try to deliver that message.
and unless that host implements a dummy SMTP server that refuses all
incoming mail with a permanent error the sending mailer will keep
getting "connection refused" - which is treated as a temporary error
and the sending mailer will keep retrying. this clogs up mail queues.
As John Levine pointed out, a message with an originating email-
address referencing a domain only containing AAAA records is likely to
be refused. In part to avoid potential issues handing NDNs as Frank
suggested, and in part that each IPv6 hostname offers a vast number of
domains and addresses that can be exploited as a spoofed source due to
the RFC2821bis fallback specifically including IPv6 AAAA records.
and the dummy SMTP server works, but it consumes resources on the
host and eats bandwidth on the network. having a way to say "don't
send this host any mail" in DNS seems like a useful thing. and we
simply don't need the fallback to AAAA because we don't have the
backward compatibility issue that we had when MX records were
introduced.
Not sanctioning IPv6 AAAA records as an MX fall-back avoids the
undesired traffic now caused by SMTP spoofing of A records. MX
records might then be seen as an opt-in mechanism from the perspective
of IPv6, since opt-out mechanism are onerous for those not wishing to
participate. While Bill and others expressed concerns of being tied
to DNS, whatever replaces DNS must also offer separate service and IP
address resolution mechanisms. The concerns related to DNS seems to
assume there would not be separate service/address mechanisms, but
this would not suit those running their services out of different
domains.
Not sanctioning IPv6 MX to AAAA fallback actually makes IPv6 easier to
manage in that email policies will not be required at all IPv6
hostnames, as they would be for IPv4. Those wanting to employ small
and simple services connected directly to the Internet might otherwise
find these services inundated by undesired traffic whenever their
hostname is used to spoof an email source. Not sanctioning IPv6 MX to
AAAA fallback makes IPv6 safer from abuse, perhaps enough to
compensate for the quadrillions of hostnames and IP addresses that
might be involved. Over time SMTP itself may not remain viable as an
exchange between anonymous parties if RFC2821bis retains IPv6 AAAA
records as a fall-back for MX records.
-Doug
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf