Re: Email Forwarder's Protocol ( EFP )

----- Original Message ----- 
From: "Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Saturday, February 26, 2005 4:44 PM
Subject: Re: [spf-discuss] Email Forwarder's Protocol ( EFP )


> On Sat, 26 Feb 2005, Stuart D. Gathman wrote:
>
> > Having said that, I should reevaluate your posts with the assumption that
> > you are actually talking about a senderID alternative, rather than
> > an SPF alternative.  You might have some great ideas that would do
> > an end run around Microsoft.  To an end-user, rfc2822 headers are
> > much more visible, and where the user needs the most help in
> > recognizing "phishing" attacks.  I say, I *should* reevaluate your
> > posts, however, I'm not really up to speed on 2822 authentication, having 
> > been
> > concentrating on the 2821 end of things.
> In particular, senderID doesn't address forwarders very well, and it
> sounds like you've given it some thought.  You may be on to something.
SenderID does address forwarders, if the header is untouched enough for that 
XML-laden piecd of computational dross to be parsed by the recipient and 
accepted as non-spam.
But SenderID is completely vulnerable to the client machine being 
zombi-laden, and if SPF clients accept it to over-rule the policy of the SPF 
domain owner, it will *OF COURSE* form a conduit for spam. In fact, since 
any spamming schmuck can and will buy SenderID keys, it can and should be 
considered as a blatant flag that the traffic is in fact spam, much as those 
little header haiku keys were very quickly shown as a popular flag that the 
content was, in fact, spam.
And remember, Microsoft collects money for each client key. Their business 
plan for selling the keys is its use for "business mail", people who will 
bother to buy the keys and use it for their commercial bulk mail. For most 
of us, such traffic such traffic is also spam in the sense of "unsolicited 
bulk communications", though not in the sense of "forged stuff from 
illegitimate companies" that much effort and legislation such as the 
CAN-SPAM act is aimed at..
Eventually, if it were to be endemic to every client *AND* every client 
bought keys *AND* Microsoft were to very tightly manage the keys so that any 
zombied machine or spam account is instantly cut off, Sender-ID might be 
useful. But that's far too many steps of both software and legal change in 
the handling of the keys and the email clients, and it's not reasonable to 
expect it to ever be effective enough to be really useful against the 
zombied and spam-front-company-purchased Sender-ID provisioned spam senders. 
They will certainly grow to fill any temporary reduction of spam caused by 
the growth of Sender-ID.
Clean SPF is useful to make spam identifiable at the sender, to reduce the 
zombie spam, and to reduce the email worm attacks so common from those same 
Microsoft-burdened email clients.