SPF deployment by Oct. 1 ?

Tue Jul 27 22:09:59 UTC 2004

On Tue, 2004-07-27 at 13:38, James Couzens wrote:
> On Sat, 2004-07-24 at 18:49, John Bittenbender wrote:
> > http://www.infoworld.com/article/04/07/22/HNmicrosoftid_1.html
> > 
> > As a side note, I notice that the article mentions a submission to the
> > IETF but I haven't seen any RFC's related, if there is one out there
> > can someone please point it out for me?
> > 
> > I didn't see anything obvious here:
> > 
> > http://www.ietf.org/html.charters/dnsop-charter.html
> > 
> > or here:
> > 
> > http://darkwing.uoregon.edu/~llynch/dnsop/
> > 
> > Looking in the wrong place?
> 
> The "MARID" version of SPF is a bastardization of the original SPF being
> called SenderID in that they are trying to cram as much crap into it as
> they can.  Although it appears that the idea of storing "SenderID"
> records in XML as DNS records has been averted I'm extremely sceptical
> that anything will come of that group in the near future.
> 
> As for people parsing SPF records and dropping email as a result of a
> FAIL response, there are some groups out there doing this.  Verizon
> tried for a few days I believe and then quickly reverted when they
> realized the error in doing so.  I think its much to soon to be doing
> this especially in view of the forwarding problem with SPF.
> 
> The MARID list is pretty useless for anyone seeking information, and
> actually its pretty useless even if you are trying to subject the
> proposed protocol to any idea you might have as many on the list have
> disregarded valid issues several times.  Perhaps this is to retain
> focus, or perhaps its because they think they know better, this is my
> opinion in view of what I have witnessed thus far.  You will find a
> better reception on the SPF-DISCUSS list as is hosted by spf.pobox.com. 
> You can find links to it on the spf.pobox.com site by clicking on the
> "Forums" link (poorly worded I know, the old site was much better).

Sender-ID employs existing SPF records intended to qualify the RFC 2821
MAIL FROM, but then fully ignores the RFC 2821 MAIL FROM.  Sender-ID
introduces "Purported Responsible Address" (PRA) from the RFC 2822
headers, where differing types trump more recent headers.  The author of
SPF and owner of spf.pobox.com dropped the MAIL FROM strategy of ASRG to
adopt this proprietary scheme of Microsoft.

PRA will not abate the bounce traffic. PRA is not able to end Phishing
as touted either.  A message can be fully validated by including a
header such as Resent-From: random.random.Starbucks.to where the From
seen by the user could be anyone.  There is no means to accredit the
administration of the domain accountable for the introduction of the
spam either.  With the typical scale otherwise needed, many publish
their records open-ended to allow mail sent from differing points of
access.  If a common relay point were published in a closed-ended
fashion, then those sharing this server would know they could forge mail
for that domain as fully validated.

The number of DNS lookups to obtain the "record set" could include
hundreds of queries.  There is a timeout of 20 seconds for obtaining
perhaps dozens of references contained within a single "SPF" record,
such as PTR, MX, A, AAAA.  If a timeout occurs, the message receives a
450 temp error and is to be repeated at some point. A new series of DNS
queries is immediately started for the next message.  Without exceeding
Sender-ID time limits, the process can continue for more than 3 minutes
per message. It also threatens network stability with high levels of UDP
traffic together with premature termination and overlay of these
queries.

With IPS's transparent interception of SMTP traffic, mail may go
missing if this is not known before hand.  Defining an "open" record set
could swamp DNS with spammer abuse.  Forget about mail forwarding
working.  But, by all means, publish, publish, publish.  Caveat Emptor. 
Publisher beware.

MARID
http://www.ietf.org/html.charters/marid-charter.html
(note, the marid-protocol links are in error).

Sender-ID drafts:
http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-core-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-rationale-00.txt

CSV drafts:
http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-intro-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-csa-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-dna-01.txt

There is an alternative solution that can do something to protect the
networks and not break mail.  The Client SMTP Validation (CSV) drafts
provides a solution to ensure the SMTP client can be both authenticated
and authorized to send mail.  If used in conjunction with SPF, it could
effectively thwart spam and Trojan systems.  PRA however, keeps the door
open. : ( 

There is a possible alternative to SPF that uses a DomainKey approach to
sign the RFC2821 MAIL FROM using the local part called Bounce Address
Tag Validation (work in progress).

http://www.brandenburg.com/specifications/draft-crocker-marid-batv-00-06dc.html

There is also work ongoing to provide an effective means to identify the
sender (work in progress).

http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-00.txt

-Doug