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

[Douglas Otis <[e-mail]>]

On Jun 26, 2009, at 3:47 AM, Ian Eiloart wrote:
> --On 25 June 2009 12:40:19 -0700 Douglas Otis <[e-mail]>  
> 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@4096.

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