Re: "SPF Sender Authentication Deployment Recommendations" draft


As I was afraid it is not what I was looking for as far as official public 
statement on the topics raised by SPF positionon SID. Some of the problems
with the text include:
 1. Its too long
 2. Its not specific enough to the differences between SPF and SID
 3. It sanctions the use of SPF1 records by Microsoft for its SID system
    by way of sanctioning the "opt-out" of publishing SPF2.0/PRA
 4. In several places instead of clarifying things for the readers it
    may confuse them when terminology is not used appropriately, for 
    example where it says that forwarding is relaying (in current SMTP 
    mode, relaying does not involve change of source or destination
    email addresses while forwarding does),there are also several other 
    places where information on cryptography solutions is not quite correct.

In reality there are just too many problems with this text that I think
it would be better for spf council to not use it and instead consider
using either original SPF Position on SID statement or draft texts that 
Greg and me worked on.

On Tue, 4 Jan 2005, Mark wrote:

Here is my second "SPF Sender Authentication Deployment Recommendations"
draft.

The only truly controversial point remains the Mid-Points, of course. I
think it should not come as a surprise that I lean towards a rather
"classic" model of SPF + SRS. Especially so, since, imho, crypto based
solutions still have some major issues to overcome, where SRS already
offers an answer.

There are those who believe section 4a ("SPF and Sender ID") should be
more of a political statement. As you may know, I have never much been in
favor of that; for one, because I think saying things like "Microsoft
stole our SPF records" or something similar, tends to make one look
'childish' very soon -- even though it may be true. I like a more
cut-and-dry, factual statement. But if the SPF community rather see a more
political statement, I will accomodate that desire, of course -- no hard
feelings. :)

Anyway, let me know what you think.

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx



------------------------------------------
SPF Sender Authentication Deployment Recommendations


1. Recommendations for Senders.

We recommend that Senders publish "v=spf1" records, so that Receivers may
authenticate designated, authorized mail servers. Senders should publish
"v=spf1" records with the MAIL FROM entity in mind. In the case where
Senders suspect "v=spf1" records to be erroneously interpreted by
Receivers as applying to either the MAIL FROM or elements of the message
header, the Sender may choose to publish a separate, void "spf2.0/pra
?all" record, so as to ensure that "v=spf1" records are only used for MAIL
FROM/HELO checks.

SUBMITTER, if supported, supersedes the use of MAIL FROM. In those cases,
expect SPF checks to be done against SUBMITTER first.


2. Recommendations for Mid-Points.

2a. Summary.

It is not what goes into your mail system which defiles your good name,
but what goes out. Thus it is the position of the SPF community, that
every Sender on the net take responsibility for his own "accountable
messaging space;" mail forwarders not excluded. In an SPF world, this
means that every outgoing message should bear the MAIL FROM stamp of
accountability for the relay in question. By consequence, we recommend
that mail forwarders do SRS on the MAIL FROM entity for mail in transit.

Forwarding is relaying. Since forwarding hops lie, per definition, outside
the scope of Senders (as Receivers determine the forwarding path), we
therefore believe that forwarding, without SRS, "breaks" IP-based
Sender Policy -- in contrast to the belief that SPF "breaks" forwarding.
As such, we believe that the 'accountable' solution for the forwarder
lies in bringing each message in transit within the purview of its own
Sender Policy Framework, using SRS.

2b. Cryptographic end-to-end solutions.

Cryptographic end-to-end solutions count on mail in transit passing
through unaltered. Making modifications after a message is signed
(especially changes to the message body) breaks the cryptographic
signature. On outbound mail this happens, for example, when adding a
disclaimer or anti-virus blurb. The more pernicious instances, however, we
believe occur on inbound mail. Specifically with the use of industry
leading Mail Filter (Milter) software.

Milters operate early in the process of accepting mail: at the
SMTP-dialogue level, long before the altered message hits the .forward
file for relaying. They typically perform tasks like MIME-reformatting,
stripping off attached files with certain extensions, replacing inline
content with links to a local store, etc. As a result, come forwarding,
the modified message has already broken the cryptographic signature. There
are several ways out of this:

1): Never alter a message in transit.

The problem with the common use of .forward files, however, is that "in
transit" is really just a description of the overall, de facto route, and
does not denote a true separate state of delivery: a Milter, at the RCPT
TO stage of the SMTP-dialogue, only sees a local recipient (the message
only effectively becomes "in transit" as the result of a later action).

Domain Keys, SES, and other cryptographic solutions, therefore, work great
on a final, local recipient: a first-in-chain Domain Keys Milter is
expected to validate the cryptographic signature, after which point other
Milters can modify the message at will. As soon as the message is relayed
over a .forward file, however, it will have potentially passed all other
sorts of Milters, including popular ones that modify the message.

Basically, a forwarded message is inbound mail, which thereafter becomes
outbound after all. Which means that, for p2p cryptographic solutions to
work properly, neither Senders nor Mid-Points can modify the message --
Receivers allowing .forward files included! We believe that short-term
expectations in this area are unrealistic.

2): Anticipate changes when signing.

We have taken notice of efforts in the cryptographic end-to-end solution
corner to try and anticipate modifications made by mailing-lists, ISPs,
etc. We believe this to be the least viable option. Any such attempt is
bound to fail, and, for the time that it works, creates a massive and
unrealistic co-dependency between Sender and Receiver.

3): Re-sign the message.

Digitally re-signing the last step in the outbound delivery chain solves
the "breakage" of modified mail for Mid-Points; but, making it essentially
a new message, "breaks" the end-to-end concept of proposed cryptographic
solutions. In simple terms: the Receiver then still has no way to
determine the authenticity of the Sender's original message; which was the
whole point-2-point!

4): Do SRS.

In any such cases where a Mid-Point modifies a message "in transit"
(including .forward file Mid-Points, and not just specialized forwarding
services), the SPF community considers the forwarder better off doing SRS
than re-signing a message. SRS is much less computational, and therefore
faster and less of a resource drain. And SRS brings the full benefit of
IP-based Sender Policy into fruition.


3. Recommendations for Receivers.

3a. Fitness of purpose.

SPF "v=spf1" records are designed and published for software which
protects and operates on the MAIL FROM entity (and, under circumstances,
HELO/EHLO). Using SPF "v=spf1" records for any other purpose may or may
not conflict with Sender Policy. Specifically, the "v=spf1" language does
not cover other parts of the message transaction, such as protecting From:
or other visible headers. Improper use of SPF "v=spf1" records may result
in unexpected/unwanted behavior. In particular, we point to the risk of
having legitimate mail rejected.

We therefore recommend that Receivers not use SPF "v=spf1" records for
anything else than MAIL FROM and HELO/EHLO checks.

3b. License encumbered technology.

The SPF community recognizes the existence of patent license encumbered
technology in today's market. It is the position of the SPF community,
however, that key components of the Internet infrastructure should remain
free of license encumbrances. As a result, we feel that license encumbered
technology, insofar as it overlaps with the use of SPF "v=spf1" records,
will hinder and/or conflict with the rapid, Open Source deployment of SPF.
We therefore recommend that Receivers only examine SPF "v=spf1" records
with algorithms that are, themselves, unencumbered.


4. Overall Recommendations & Notes.

It is in the very definition of stopping forgeries that you disallow
certain things which were allowed before. If you sign messages, no one
thereafter must change them; if you forward, you change relay, and must
change accordingly. Whatever you do, putting restrictions on something
means that sooner or later someone, somewhere, will have to give up doing
something which he merrily did before. If we're not willing to take that
step, then we're not willing to stop forgeries.

SPF Classic has already been deployed in many antispam and MTA products,
and currently enjoys the support of an estimated 1 million domains. We
therefore encourage continued development of SPF Classic in the email
industry. We furthermore encourage continued development and exploration
of other possibilities in the accountable messaging space, including, but
not limited to, Identified Internet Mail and cryptographic solutions, like
Domain Keys, SES, S/MIME, and PGP.

4a. SPF and Sender ID.

As there has been some confusion on the relationship between SPF and
SenderID, we would like to clarify the relationship. While Sender ID
reuses existing SPF records to perform the PRA test, SPF Classic is not
Sender ID, and Sender ID is not SPF. The two technologies are
complementary, but they operate on different parts of the message and
serve different purposes.

Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com


-- 
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net