Re: Last Call: draft-klensin-rfc2821bis

[Douglas Otis <[e-mail]>]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf