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