Re: Limited scope of work

Andrew Newton wrote:
> The proposed charter of this working group (and the BoF which has led to 
> this point) have a limited scope and a limited timeframe.  Since the 
> initial pick list of identities was given, some of the proposals are 
> leaning toward more grandiose mechanisms than previously proposed.  
> Please keep in mind that the scope of the work here is to be limited to 
> problems in the area of MTA authorization and the class of spam that may 
> be stopped by this type of authorization (i.e. not spam generated from 
> compromised hosts, ill-meaning senders, etc...).
I am not sure why spam from compromised hosts is out of scope since MTA 
MARK and DRIP are designed to stop those types of spam.
> Therefore, we once again ask the participants of this list to focus on 
> the following identities:
> 2821 HELO/EHLO domain
> 2821 MAIL FROM
> 2822 From:
> 2822 Sender:
> New structure/RR's in .arpa *
IMHO, I think that we should focus on RFC2821 HELO and in-addr.arpa 
first since they seem to break the least amount of things. Also, if HELO 
arguments are domains then it is possible to apply reputation and 
accreditation services based on domain names.
I am less enthusiatic about MAIL FROM checking since I do not see how it 
will reduce spam in the long run without reputation (i.e. vanity 
domains). If the entire purpose of MAIL FROM checking is to introduce a 
hook for reputation, than HELO with domain names will satisfy that. 
Simply reducing bounces from joe jobs does not seem a good enough reason 
for me to break the store and forward functionality of email and forbid 
many legit uses. The main problem here is how to tell whether an MTA 
should be trusted. HELO or in-addr.arpa checking combined with 
reputation/accreditation systems should be sufficient for that. Once you 
establish a trust level of a given MTA, than you can trust that MTA to 
provide you with non-forged headers and bounce addresses. If you trust a 
specific MTA to trust its incoming MTAs further down the line, than you 
might be able to keep the store and forward functionality intact.
As for From and Sender headers, I think that other mechanisms can do the 
job better such as DomainKeys or passing the informaton explicitly in 
SMTP such as in SMTP AUTH's MAIL FROM extension for passing author's 
address.
Yakov