ietf-mxcomp
[Top] [All Lists]

RE: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

2005-08-26 11:48:54

On Fri, 2005-08-26 at 10:23 -0700, Hallam-Baker, Phillip wrote:
<snip>
I do not believe that one group should be able to block a proposal they
do not like by alleging a non-existent conflict.

A conflict does exist interpreting v=spf1 records in a PRA scope. I had
a customer who was a victim of joe-jobbing. We use separate domains for
RFC821 and RFC822 identities. The RFC821 identity (MAIL FROM) would
never be used as a RFC822 identity (FROM).

RFC821 FROM: foo(_at_)customer(_dot_)bounce(_dot_)esp(_dot_)com
RFC822 From: branding(_at_)brand(_dot_)esp(_dot_)com

Before Sender-ID came I had this:

brand.esp.com   IN TXT "v=spf1 -all"

This means if brand.esp.com was ever seen as a RFC821 MAIL FROM domain,
it could be considered a forgery.

Along comes Sender-ID, reusing v=spf1 records for PRA tests. Microsoft
then decides to put a warning for those records that fail Sender-ID
tests for its Hotmail/MSN users.

Since Sender-ID checks RFC822 identities against a record meant for
RFC821 identities, it gets an erroneous FAIL.
 
This is what I believe is the conflict. It is real. It exists. In order
to get correct results I have to publish 2 records in DNS:

brand.esp.com   IN TXT "spfv2.0/pra a:outbound.brand.esp.com -all"
brand.esp.com   IN TXT "v=spf1 -all"

OR (this one opts out of Sender-ID):

brand.esp.com   IN TXT "spfv2.0/pra"
brand.esp.com   IN TXT "v=spf1 -all"

This also means that to participate in one experiment I have to
participate in another. That seems wrong to me.


-- 
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | jmacdonald(_at_)e-dialog(_dot_)com
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com