Well, draft-ietf-marid-protocol-03.txt was very disappointing, so I went
ahead and did what needed doing.
I made some edits and made a new Internet-Draft based on it: SPF3.
I summarize the changes as follows:
s/typos/corrections/
s/Most of 6.2 Processing Limits/<new text>
s/mail from or PRA/HELO/
s/mfrom,pra/helo/
s/spf2.0/spf3.0/
s/Mark,Meng/me/
s/SenderID/SPF3/
Some tweaks to the Abstract.
Allow SPF1 records to be used. Strangely,
draft-ietf-marid-protocol-03.txt didn't allow this!
The effort put into the edit may have produced something of lesser
quality than one expects from Microsoft.
Comparison of SPF3 and CSV+MPR:
Organizationally, it's superior, in that it leverages the existing base
of SPF1 records. It's easier to understand, includes examples, and it's
easier to create TXT records - of bind, GoDaddy and ZoneEdit, only BIND
supports what CSV requires.
Technically, it's inferior, in that its usage of DNS is less efficient
and less standards-based. MPR also has the cool bitmapped fields for
explicit protection of 2822.From:, etc. This could be added to SPF3.
Comparison of SPF3 and SPF1 or SenderID:
It's superior, in that it doesn't break forwarding, is much more
efficient, and can't be tricked by forged or misleading headers,
requires about 99% less effort to implement, on a global basis, is
based on an algorithm that predates M$' patent filing, and provides
something that can be better accredited.
=-=-=-=-=
Rest of this post: Re: HELO and Unified ; new scope? ; Microsoft oops; BCP
On 9/15/2004 12:58 AM, David Woodhouse sent forth electrons to convey:
My suggestion is that we should go forward with an entirely _different_
scope, not just unify on either mail-from or whatever the unencumbered
pra replacement would be.
There are many possibilities which would offer us some 'handle' on the
owner of the mail server in question, without all the problems which
both mail-from and pra scopes suffer.
The 'handle' needs to be something non-free, otherwise spammers will
make an infinite number of them.
Domains are a good choice. A domain with a valid SSL cert would be
another choice.
Spamhaus.org's .mail proposal would be another good choice.
Unsigned certs or signed thawte freemail certs would not be acceptable.
=-=-=-=-=
There's a false statement in Microsoft's previous IPR disclosure statement:
VIII. Other Notes: ** A license to implement these specifications
will be made available at http://www.microsoft.com/mscorp/standards on
or before September 15, 2004.
http://www.microsoft.com/mscorp/ip/standards/ has it.
=-=-=-=-=
On 9/15/2004 4:16 PM, Frank Ellermann sent forth electrons to convey:
Matthew Elvey wrote:
we have been asked by the DNS people to refrain from putting
additional load on the PTR system if possible.
(And the mess of mis/unattributed quotes continues. I didn't write that.)
Oh, I missed that request. A pointer and/or quote would be
appreciated if it wasn't made on this list.
<http://article.gmane.org/gmane.ietf.mxcomp/2707/match=apnic>
Thanks. An interesting thread. It suggests that the RIRs have little
to worry about.
If MARID is halfway successful, the load on their servers is likely to
go way DOWN.
PTR lookups are already the norm. MARID should cut mail volumes are cut
by more than half (most mail is spam), so PTR lookups can be expected to
go down as well.
BTW, RIR gross failure to address their responsibilities, as evidenced by
http://www.spamhaus.org/sbl/listings.lasso?isp=APNIC ,
(not to mention
http://www.spamhaus.org/sbl/listings.lasso?isp=ARIN ) <ahem> well,
umm... I...
They're knowingly providing Spam Support Services...
=-=-=-=-=
With respect to being able to outright reject forgeries without breaking
forwarding:
With HELO checks + A&R, I can see this becoming reasonable BCP. Here's how:
Forwarders (and mailing list hosts) will be expected to be runnning
MARID on their MTA. If they are too lazy to do so, then they will be
found to be forwarding on obvious (to anyone using MARID) forgeries, and
thus their reputations will (justifiably) suffer. It will probably not
be fair to blame 'em for all spam they forward, but it will be fair to
blame them for forwarding on obvious forgeries. The responsible
forwarders running MARID can be expected to have good HELO reputations.