ietf-mxcomp
[Top] [All Lists]

Re: MARID compatibility with SPF records

2004-07-17 06:57:21


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.