Re: MARID compatibility with SPF records

On Jul 17, 2004, at 12:45 PM, Mark Lentczner wrote:
> But the real question in my mind is, while I understand the semantic 
> difference from a purely technical point of view, I'm not sure that I 
> can find a practical difference.  Specifically, I'm not sure I can 
> find a case where:
> 	There is a domain that identifies at least one host that it permits 
> to be used as the PRA
>         but not as envelope MAIL FROM.
> or
> 	There is a domain that identifies at least one host that it does not 
> permit to be used as
>         PRA, but does permit as envelope MAIL FROM.
>
> For simple mail, the envelope MAIL FROM and PRA are the same.  So any 
> case must involve more complicated mail set ups: forwarding, lists, or 
> bulk mail.
> On Jul 17, 2004, at 6:57 AM, Margaret Olson wrote:
> > Problems occur with domains where the MAIL-FROM matches the PRD in 
> > one system (for example the mail sent by an ISP), and that domain has 
> > published an SPF v1 record, and that domain is used as the PRD (2822 
> > from) in another system with it's own error handler. In other words, 
> > in domains that have an ISP for personal mail and at least one 
> > outsourced service that sends specialized mail (for example a 
> > shopping cart or a email service provider for marketing messages).
> Margaret gives two examples, the first of which she declares to be 
> "not a problem", since it is solved by businesses having their own 
> domain name.  I'm going to restate the second example to be sure I 
> understand it, and to see if it fits the test above:
> mybikeshop.com normally sends it's mail via its ISP's servers at 
> bigisp.com, however, it sometimes sends bulk mailing to its customers 
> via bulkmailer.com.  Hence, we see normal messages as:
>         SMTP client:        mx.bigisp.com
>         envelope MAIL FROM: amy(_at_)mybikeshop(_dot_)com
>         header PRA:         amy(_at_)mybikeshop(_dot_)com
>
> and we see bulk messages:
>
>         SMTP client:        mx.bulkmailer.com
>         envelope MAIL FROM: 
> bounce+mybikeshop(_dot_)com(_at_)bulkmailer(_dot_)com
>         header PRA:         amy(_at_)mybikeshop(_dot_)com
>
> So the records involved are the SPF records for bulkmailer.com and 
> mybikeshop.com.  We'll take these in this order.
> bulkmailer.com needs to publish a record that old, envelope MAIL FROM 
> checking SPF implementations will pass when seeing the second type of 
> e-mail.  So it publishes:
>         bulkmailer.com. IN TXT "v=spf1 +a:mx.bulkmailer.com -all"
>
> If this record is used by a newer implementation that checks PRA, this 
> almost certainly valid since bulkmailer.com could send its own mail 
> (where it is in the PRA) from this machine.  Even if it didn't, it 
> administratively controls this machine, and is already accepting 
> accountability for it.  Such a declaration doesn't result in a loss of 
> reputation or an opportunity for a spammer.
> mybikeshop.com needs to publish a record that envelope MAIL FROM 
> checking SPF implementations will pass when seeing the first type of 
> mail, and newer implementations will pass with either.  So it 
> publishes:
> 	mybikeshop.com.	IN TXT "v=spf1 +a:mx.bigisp.com +a:mx.bulkmailer.com 
> -all"
> This record is slightly more liberal than the requirements.  In 
> particular, implementations checking envelope MAIL FROM against this 
> record will Pass an envelope MAIL FROM with mybikeshop.com when coming 
> from mx.bulkmailer.com.  Given that mybikeshop.com already trusts 
> bullkmailer.com to use its name as PRA on e-mail, it seems unlikely 
> that mybikeshop.com would be unwilling to trust that they could set up 
> the envelope MAIL FROM correctly.
I completely agree up to this point.

My question is: what mybikeshop.com's ISP has *already* published an 
SPF record for mybikeshop.com, without taking sender id into 
consideration? Given that SPF has been around longer than Caller-ID, 
and the syntax merger is extremely new, it is not unreasonable to 
expect that this situation exists. In this scenario, mybikeshop.com's 
SPF record probably looks like:
mybikeshop.com IN TEXT "v=spf1 +a:mx.bigism.com -all"

This is currently correct in an SPF classic context and produces the 
desired result of SPF classic: it protects against MAIL-FROM forgery. 
But it's not a correct SenderID record - the correct SenderID was shown 
in Mark's text above, and includes bulkmailer.com.
At what point is it safe for receivers to assume that mybikeshop.com's 
records have been updated and apply the SenderID PRD algorithm? (Here 
"updating" is meant to include the several approaches available, 
including literally updating the mybikeshop.com record and creating 
sub-domains for the transactional and bulk messages.)
I do not know how big this problem is, but given that there are 10s of 
thousands of domains publishing SPF records, and many 10s of thousands 
of domains (perhaps millions, depending on whose numbers you believe) 
using outsourced providers, it's reckless to assume that it is not a 
practical real world problem.
So I think we *do* need to express the record version. I am inclined to 
agree with Mark's point that there isn't any practical need for a 
permanent scoping mechanism.
Short of proof that there is no overlap between currently published v1 
records and clients of ESPs and clients of outsourced shopping carts 
record differentiation of some sort is mandatory. Otherwise we 
introduce a situation where publishing is  potentially more damaging 
that not publishing, which is a sure way to kill publication. I suppose 
the other possibility is that an authentication failure comes to have 
relatively little meaning, but that is hardly a desirable outcome 
either.
Margaret.