ietf-asrg
[Top] [All Lists]

Re: [Asrg] draft-irtf-asrg-criteria is missing Outbound MTA definition.

2009-06-26 14:40:06

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