Douglas Otis wrote: > 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 >> http://www.exim.org/exim-html-current/doc/html/spec_html/ch32.html#SECID162 >> >> >> 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: > http://www.imc.org/ietf-smtp/mail-archive/msg04444.html > > 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. > > -Doug
+1
