[SpamCop-List] Re: OT SPF is harmful. Adopt it

[Julian Mehnle]

Mike Easter wrote:
> Well, I'm not anti-SPF, and I'm certainly not pro-IM2000, promoted by
> JdBP, which I don't think will ever go anywhere;  but...
> 
>  - SPF has some real issues that it is going to have to deal with

I'd never dispute that. :-)  But the difference between me and 
fundamentalists like JdBP is that I'm not afraid of making sensible and 
appropriate changes to the current e-mail system, without resorting to 
throwing all of it away and starting all over.

>  - if it could be 'let's just do it', the IETF wouldn't have temporarily
> given up trying to get a consensus for MARID acceptance in favor of
> 'let's just try (this) for a while and see how it goes'
 >  - even the Anti-Spam Research Group of the IRTF of the IETF link to the
 > Marid Wg at  http://www.ietf.org/html.charters/marid-charter.html target
 > seems to have disappeared

By definition, no change to the current system that *effectively* fixes 
any of its ambiguities[1] can ever be "let's just do it".  The MARID wg 
has been terminated (its charter is now at [2]) due to various reasons.

First, Meng Weng Wong, the SPF project leader, had made the mistake of 
allying himself with Microsoft to form the joint proposal "Sender ID".  As 
some participants of the SPF project had prophecied, Microsoft tried to 
seize intellectual property rights connected to Sender ID and SPF by 
filing a patent.  The MARID working group chairs continuously failed to 
respect the numerous complaints (among others, from the authors of the 
various market-leading open-source MTAs) against the adoption of an 
IPR-encumbered standard and in the end declared a lack of concensus 
regarding the IPR issue.

Second, there was a lot of fundamentalism among the MARID wg participants. 
  From storing verbose XML-formatted authentication info in DNS records, 
up to canceling any real authentication effects by not checking the 
envelope sender (and thus doing nothing to prevent misdirected bounces and 
auto-responders) -- if it just was esoteric and eccentric enough, it sure 
has been proposed and fought for fundamentalistically on the MARID mailing 
list.

Footnotes:
  1. Ambiguities are where conceptual (not implementation-specific) 
security problems generally result from.  SPF in particular fixes the 
ambiguity in RFC (2)821 that the envelope sender (MAIL FROM) is overloaded 
to mean both the originating address and the address where to send error 
messages.
  2. http://www.ietf.org/html.charters/OLD/marid-charter.html