[Top] [All Lists]

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

2008-04-18 16:39:41

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

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.