Subject: SPF and SenderID /MARID comparisons

From: "Olson, Margaret" <[email-masked]>
Date: Mon, 14 Jun 2004 21:53:45 -0400

This is a follow up to the discussion on jabber this afternoon, on comparing
SPF records to SenderID/MARID records.
 
Limiting the comparison to just the size of the records is misleading; the
usage of SPF and SenderID is quite different and you have to take into
account other factors.

Most non-technical small business domains outsource some or all of their
email. It's not just email that a small business will outsource, it's almost
everything technical and it's usually outsourced along function/feature
lines rather than by role. In other words, they don't have an outsourced IT
department, they have outsourced problem solutions. A local design firm
created the web site and it is hosted at a small business hosting provider.
The ecommerce shopping cart is hosted somewhere else. Person to person email
is the local ISP. Email marketing is yet another company. That makes up to
three providers for sending email, none of them related to one another.

For each of these three email providers, bounces are handled by the provider
in a manner appropriate to the function provided. Generally, for person to
person mail the bounces go back to the sender. For the other two, the
bounces are handled by the application. If you look at SPF version 1, each
provider publishes for his or her domain and there is no coordination
between the various means that the same sender uses to send mail. But it's
highly likely that the purported responsible domain in all three cases is
that of the sender. So for SenderID/MARID, there is a new record which
points to three other records: one each for the ISP, the shopping cart, and
the email marketing service.

For large companies, the tangled manner in which they send mail is even more
complicated, with multiple departments each outsourcing to multiple
providers.

Using the PRD will mean that far more domains will need to be publishing
SenderID records than are publishing SPF records to get the same level of
participation. But, most of these new publishers will just have one or more
<indirect> entries pointing elsewhere, where "elsewhere" is an organization
that is a spf v1 publication candidate. With all of the sending methods of a
domain documented through the MARID records, you can hold the domains each
responsible and track their behavior across their providers. This is the
only way to curtail the extremely aggressive marketers. It is secondary to
preventing forgeries, but at the same time it is critical to solving the
spam problem.

Those of you who shop at small online businesses can see some of the sending
method mix yourselves by carefully examining the headers of transactional,
person to person, and promotional messages. If you get messages from more
than one part of a large, decentralized company you can examine those
headers and get a sense of the diversity of sending methodologies in that
part of the market.

In summary, with SenderID the mix of domains publishing will change, and the
characteristics of the records will change. I do not see a problem here, but
I do caution the group about drawing conclusions about record and
publication characteristics based on the SPF experience.

Margaret.

---

From: wayne <[email-masked]>
Date: Tue, 15 Jun 2004 10:59:08 -0500

> SPF records to SenderID/MARID records.

thanks!

> [ details deleted ]                                     That makes up to

Ok

> the email marketing service.

SPFv1 has long had both include: and redirect= that, from what I can
tell, would handle these situations just fine.

> complicated, with multiple departments each outsourcing to multiple

I can believe that.

> participation.

I don't understand this at all.  To the best of my knowledge, there is
no semantic difference between the SenderID and SPFv1 records.  They
both have the same features and use the same algorithm.  The only
difference is the syntax.  Granted, the syntax difference may (but by
no means must) allow for future differences in semantics, but until
that happens, they are, as Jim Lyon pointed out, isomorphic.

-wayne