Re: MARID compatibility with SPF records

On Jul 17, 2004, at 6:59 AM, Andrew Newton wrote:

> On Jul 16, 2004, at 8:21 PM, Roy Badami wrote:
>
> > This is an issue that the WG was supposed to have decided upon some
> > time ago, but I've seen no discussion on this.
> Agreed.  Nobody is talking about this issue, even though it is 
> important and is a technical issue.
My understanding from reading draft-ietf-marid-protocol-00 was that 
"spf v1" was being redefined to use the PRD algorithm. I don't think 
this works, but perhaps I have missed something.  I'm a bit behind in 
my reading or I would have commented earlier.
There are two basic cases: the MAIL-FROM and the PRD match (SUBMITTER) 
match, and the MAIL-FROM and SUBMITTER don't match. For mail with a 
matching PRD and MAIL-FROM, the spf v1 and sender id records are the 
same and there is no need to make any changes. For domains without at 
matching MAIL-FROM and PRD, it is highly likely that the MAIL-FROM is a 
bounce manager of some sort, in which case the MAIL-FROM is never the 
SUBMITTER, and the spf v1 record for the MAIL-FROM domain is still 
valid. There either is or is not a record for the PRD, and the sender 
id algorithm proceeds on that PRD domain.
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). I think this situation 
is common for small businesses and far more common in general than this 
group has given it credit for.
In this situation, there are two basic cases: the first is an ISP 
customer is using an ISP shared domain (e.g. aol.com, hotmail.com) as 
the PRD to send mail through some other service, for example 
mybikeshop(_at_)bigisp(_dot_)com . In this case, bigisp.com may not wish to allow 
this, and almost certainly doesn't want to give a blanket permission 
for mail from any of their customers to come from outsource provider 
xyz just because one of their customers wishes to allow this. So I 
would call this case "not a problem" for MARID, although I'll predict 
that the use of consumer addresses for business is pretty common and 
that this will some level of unhappiness and turmoil. (I also firmly 
believe that at $5.00 for the low cost providers and $25.00 for the 
high cost providers, asking even the teeniest of businesses to get 
their own domain name is not the slightest bit unreasonable).
The second case is where the ISP customer has their own domain, managed 
by the ISP, e.g. me(_at_)mybikeshop(_dot_)com(_dot_)  If the ISP has published spf 
classic records, this currently works in almost all cases: the non-ISP 
mail services use their own domain in the MAIL-FROM, and in many cases 
(about 70%) the customer domain is the PRD. This breaks the moment 
someone interprets the spf classic records as a sender id record. Here 
I think it behooves mail administrators to make sure they actually know 
how their customers send mail.  I do not have any good information on 
how many mail admins have published spf records on behalf of client 
domains (as opposed to their own domains). If this number is small to 
non-existent, than this is a non-problem.
Both these problems are fixed with either a separate SPF version for 
sender id or sub-domains assigned to specific outsourced providers. For 
people using their own domain, sub-domains are probably the best long 
term solution, but they do need to be set up.  My concern is that 
things that work now will break in chaotic ways; records will be valid 
at one receiving domain (implementing spf classic) but not at another 
(implementing sender id). No matter how much educating we do this will 
be a problem.
Since it is safe to interpret a v2 record as v1, v1 receive side 
implementations would at a minimum need to modified to accept v2 
records. Alternately, we could have a form of v2 record that said "go 
look at the v1 record" for those domains where the v1 and v2 records 
are the same.
Margaret.