On Jun 26, 2009, at 3:47 AM, Ian Eiloart wrote:
--On 25 June 2009 12:40:19 -0700 Douglas Otis <dotis(_at_)mail-abuse(_dot_)org>
wrote:
This draft overlooked an important area. It assumes a viable and
scaleable means to identify initial senders when confronting
massive levels of abuse.
Which section assumes that.
http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html
Section 1.3.1 defines "Sender" as something responsible for creation
and initial entry of a message into the Transport System and should be
identified by RFC 5321.
The 1.3.1 definition necessitates indirect assessments of the outbound
MTA which is not good. Section 2.1.2.1, when followed, precludes most
"Sender" IP address authorization schemes as potentially burdening
innocent third party DNS servers or their networks. For example,
DNSSEC expects EDNS0(_at_)4096(_dot_)
This draft fails to include a definition that encompasses a crucial
and safe point of control essential for effective spam mitigation.
The missing definition is that of the Outbound MTA, the entity
granting access and facilitating public SMTP exchanges to other
domains. Email-Arch's definition tends to understate the role with:
Outbound MTA, an MTA that relays messages to other ADMDs.
Simply put, without a two tier approach to abuse that begins by
identifying outbound MTAs, email will not remain viable. This
paper overlooks that need.
I think that's a different level, isn't it? That's a proposal to be
judged by the criteria in this paper. The paper shouldn't make any
claims about how to prevent spam. It's just trying to outline the
problem space.
What level? This paper is about the management of spam. Failing to
offer a definition of a crucial and safe management point suggests a
desire to ignore this aspect of control. Today's spam levels
necessities exclusion of messages from outbound MTAs demonstrating
poor stewardship at removing access from abusive message sources.
This approach scales since it expects a hierarchy of spam management.
Often assessments of stewardship is measured in many ways, which might
include responsiveness to reports of abuse. It is no longer
reasonable to assume spam can be filtered based upon purported message
sources. The existence of bot-nets necessitates MTA triage, where the
entire MTA message stream is handled as one. For the MTAs accepted,
only then individual message assessment becomes possible.
As email begins to accept IPv6 exchanges, traditional IP address
blocking strategies are unlikely to scale in a manner that offers
efficacy. Expecting stable and verifiable host name EHLO
announcements will dramatically reduce the efforts of collecting
stewardship histories which can be immediately applied during initial
SMTP connections. This requirement tends to exclude the use of a
large number of MTAs behind a common NAT. Often such instances
represent networks containing uncontrolled, compromised systems.
However, the current use of IP address block-lists are also likely to
exclude the use of a large number of MTAs behind a common NAT.
At Today's level of abuse, it is not reasonable nor safe to execute
hundreds of DNS transactions to verify possible MTA authorizations in
response to every SMTP connection. It should also be noted that SPF
schemes include macros that might negate DNS caching effectiveness.
A reasonable and scaleable approach that should take email safely into
IPv6 is described in:
http://mipassoc.org/csv/
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg