[Top] [All Lists]

Re: I-D Action:draft-klensin-rfc2821bis-10.txt

2008-04-18 15:57:34

On Apr 18, 2008, at 3:27 AM, Tony Finch wrote:

On Fri, 18 Apr 2008, Paul Smith wrote:

- Implicit MX. This causes me problems by (a) bunging up my mail server retry queue, and (b) loading my non-mail server hosts with the thousands of bounces to forged messages trying to be sent to them. (a) might be easy to spot, but is nearly impossible for me to fix (without 'stretching' the standard - eg by having different retry algorithms for implicit vs explicit MX records), (b) is hard to spot what's happening without a packet tracer and knowing how to use one and is hard to fix since i need to do something to add 'non- MX' records to all my hosts, which could be hundreds of 'non-MX' records.

Different retry algorithms for MX-less domains is already standard operational practise. For example see timeout_connect_A and refused_A at

I think you're exaggerating the problem that a few SYN packets cause.

Paul makes valid points. The size of the problem depends upon the non- SMTP host implementation and the size of its network. After all, IPv6 permits a greater number of devices on the Internet.

John Levine offered an example:

This example was a host not running SMTP continuously receiving undesired attempts for 30,000 spams per day. This also likely includes traffic needed to establish whether port 25 connections are possible by legitimate MTAs checking return paths upon message reception. If the host represented an intelligent parking meter over a slow IPv6 wireless network, this undesired traffic may not be considered negligible. Several have suggested the means to avoid this undesired SMTP traffic is to publish bogus MX records for each host. The bogus MX records direct undesired traffic to the root servers. (Yet another entity needing to pay for the AAAA implicit MX record convenience.)

The convenience afforded to administrators of IPv6 AAAA only SMTP servers comes at the expense of those receiving SMTP traffic and those administrating other protocols. Ironically, those sensitive to abuse directed to SMTP are expected to endure it or redirect this traffic to root servers by publishing bogus MX records. Standardizing on AAAA being implied MX records thereby increases overall administrative burdens, SMTP server overhead, and yet ultimately this is likely to prevent interoperation due to ensuing defensive strategies. The future of SMTP and IPv6 is better protected by _not_ sanctioning AAAA as implied MX records and warning about the possible deprecation of A records as implied MX records. This would move toward establishing the consistent treatment of A and AAAA records, and properly acknowledging the rising levels of SMTP abuse.