I suggest adding the following to the SPF draft
to mention its unpatented nature, to clarify that SPF still
halps vs. disreputable domains, and noting that SPF whitelisting
is a reasonable (I think RECOMMENDED) thing to support.
I'm looking at spf-draft-20040209.txt:
At the end of the Introduction:
SPF is, to the knowledge of the authors, not
encumbered by patents. Patent licensing can significantly
impede or halt adoption of any change to email processing.
{This is an advantage of SPF, document it}
In "9.1 Adoption by disreputable domains", it says:
Whether a given domain is reputable or not is a decision that belongs
to an SMTP receiver. Policy decisions regarding particular messages
are outside the scope of SPF."
add:
"However, note that SPF does aid an SMTP receiver in making these
decisions. With SPF, organizations may work to determine the
reputation of a sender, and make decisions about those reputations,
with increased confidence."
In "9.4 Verbatim Forwarding", you make an unwarranted
presumption that everyone's going to rewrite
their envelopes. I suggest that is COMPLETELY unnecessary.
For many folks, a whitelist of "trusted forwarders" is ALL they
will EVER need, particularly if it handled per-user.
I don't think this a "transitional" period at all; it's
simply another option. Some folks may choose to have their
FORWARDER check the SPF data, and the later systems may completely
trust that forwarder... and it all works just fine.
For me, my forwarder doesn't move often. It may be easier to get
the folks who manage my end-user mailbox to "SPF whitelist" my forwarder.
At the least, it gives me an alternative to trying to implement SRS
on the forwarder, which has its own problems.
So instead of this:
Forwarding hosts will need to rewrite the envelope sender as well to
maintain SPF conformance.
The rewritten envelope sender can take a variety of forms, depending
on whether bounces should be forwarded back to the original sender.
If bounces are unimportant, the rewritten sender could be as simple
as <nobody(_at_)example(_dot_)com>. If bounces are important, forwarders can
use envelope encapsulation with a MAC nonce, or rewrite the address
into a database-backed cookie.
A DNS whitelist (or its domain-name equivalent, a Right-Hand-Side
Whitelist (RHSWL)) of well-known trusted forwarders can help ease the
transition.
I suggest this:
Thus, either (1) forwarding hosts need to rewrite the envelope sender
as well to maintain SPF conformance, or (2) downstream hosts must
be configured so that they do not examine SPF data from those
forwarding hosts.
(Keep "the rewritten envelope sender...").
Alternatively, downstream receivers can use various means to
determine that the forwarded email can be accepted as-is,
without (re) performing SPF filtering (which may have already
been done by the forwarder).
A DNS whitelist (or its domain-name equivalent, a Right-Hand-Side
Whitelist (RHSWL)) of well-known trusted forwarders could be used.
A downstream receiver could use a specially-configured "SPF whitelist"
for itself. An SPF whitelist contains a list of IP addresses and hostnames
(which are resolved into IP addresses), and then compared to the
IP address of the incoming message. If they match, then SPF checking
would be skipped. Such a whitelist can be implemented for all email
entering the receiver, or even be customized to be per-user.
It is RECOMMENDED that SPF implementations at least support
SPF whitelists that apply to all incoming messages.
--- David A. Wheeler