In <20041025170706(_dot_)28EE6606(_at_)dumbo(_dot_)pobox(_dot_)com>
mengwong(_at_)dumbo(_dot_)pobox(_dot_)com (Meng Weng Wong) writes:
I just got off the phone with Paul_Roberts(_at_)idg(_dot_)com who is
writing a story on Sender ID. I gave him my opinion that it
was a good thing that MS's PRA checks could reuse v=spf1
records.
Thanks for the heads-up Meng. I sent the following message off to
Paul. Anyone who thinks I blew it with this message is free to
correct me and/or send Paul info.
Hi.
Meng Weng Wong just mentioned on the SPF-discuss mailing list that he
talked to you about Sender ID and and re-using SPF records.
I am Wayne Schlitt and I have been involved with the SPF project since
near the start, I am the author of one of the most widely used SPF
systems, and I was very active in the IETF MARID working group.
As you probably know, the SenderID standard was being developed by the
IETF, with input from many people including those from Microsoft, the
SPF community, Sendmail, ISPs, etc. As you probably also know, this
working group was shut down around a month ago due Microsoft's demands
for patent license terms that would be incompatible with most mail
servers that are on the Internet now, and for technical problems with
the Sender ID specification.
See, for example, these stories:
http://www.eweek.com/article2/0,1759,1644616,00.asp
http://www.internetnews.com/dev-news/article.php/3411461
I don't know who exactly CircleID is, but they published a very good
series of articles on the whole mess. See:
http://www.circleid.com/article.php?id=P765_0_1_0_C
http://www.circleid.com/article.php?id=P756_0_1_0_C
http://www.circleid.com/article.php?id=P732_0_1_0_C
http://www.circleid.com/article.php?id=P730_0_1_0_C
These articles were written by experts who were very much involved
with the whole IETF MARID working group and SenderID situation.
As a result of the IETF shutting down the MARID working group, no
final specification for SenderID has been delivered. There are
incomplete specs floating around, but they all have technical problems
with them.
One of the issues that the IETF *did* resolve before shutting down
MARID was that SenderID should *not* re-use existing SPF records, and
the last set of SenderID specifications completed by the IETF said so.
There are good technical reasons for this decision. I don't know how
many technical details you are interested in, so I'll try and give you
a very simple explanation. Please feel free to ask me any questions
you have.
There are many cases where using existing SPF records will give the
wrong answers if they are used by SenderID. A simple example is a
small business that runs their own mail system and website, but they
outsource their web purchasing to another company because of the
complexities of dealing with credit cards and such.
This small business may well have published SPF records saying all
email claiming to be from them comes from their mail server. This
works fine with SPF. This may not, however, work with Sender ID.
There are actually a couple of different "identities" that are used
when email is sent. SPF checks something called the "envelope from",
identity which, as it sounds, is analogous to the "from" address on
the envelope of the regular letter. SenderID checks something called
the "From: header" identity, which is analogous to the "from" address
on the letter head of the letter. Just like with regular mail, the
"envelope from" is not always the same as the from address on the
letter head.
When the small business outsources their purchasing to another
company, the "envelope from" is usually the address of the outsourcing
company. This is so that any problems with mail that can't be
delivered can be dealt with by the outsourcer instead of making the
small business having to deal with it. However, the "from" address of
the letter head and/or the "From: header" will be that of the small
business.
The SPF records that the small business created deal only with the
from address of the envelope. When someone uses SenderID to check the
wrong from address, they will find that the outsourcer is not allowed
to use the small business's address, which is wrong.
As such, I believe that using SenderID with existing SPF records is
risky, and the IETF agrees. I also believe that using SenderID at all
right now is risky because there has never been a complete
specification. The technical flaws of SenderID still exist and the
IETF didn't think such problems could be resolved.
-wayne