I would like to suggest the use of the SMTP DSN extension ORCPT
("Original Recipient", see RFC3461 section 4.2) as a way of handling
forwards as an alternative to SRS.
Suggested SPF Changes:
======================
Currently SPF runs its tests based on the value of MAIL FROM. I would
suggest using both MAIL FROM and ORCPT.
Or to be more precise, I would suggest changing SPF to:
1. Allow recipients to set a Recipient Policy in which the
Recipient can choose between saying one of these three
things: (I'm speaking loosely here.)
o Accept all non-forged forwards, (default--effectively
the same as SRS)
o Accept only non-forged forwards from a list
of original recipients they specify, or
o Accept no forwards.
(I'm assuming that the recipients didn't chose to forgo
all SPF testing of incoming emails.)
2. Then, when running SPF tests on incoming emails:
o If there is a value of ORCPT that matches the Recipient's
Policy, run an SPF test using that ORCPT value.
o If an ORCPT-based SPF test is run and returns PASS,
then return PASS as the final SPF result.
o If an ORCPT-based SPF test is not run or does not
result in a PASS, then run an SPF test based on the
MAIL FROM value.
o Return the better answer of the MAIL FROM-based SPF test
and the ORCPT-based SPF test (if one were run) as the
final SPF result. ("Better" meaning the closer-to-a-PASS
result.)
To me this would seem to solve the forwarding problem completely, and
without the need for SRS.
Ramifications involved in those changes and dropping SRS:
=========================================================
Dropping SRS and adding ORCPT-based tests to SPF means:
1. No return-path rewrites are required:
2. We don't have to continue to debate the best way
of rewriting return-paths. (SRS is a standard that
is still being tweaked.)
3. We no longer have to convince others of the sanity of
return-path rewrites. (Not that I personally believe
such objections are entirely logical, but now it would
be a moot point.)
4. It is no longer necessary to continue to push for
implementation, (and testing, debugging and continued
development) of SRS.
5. It's likely that end users will more quickly understand
the need for ORCPT than they will understand SRS, thus
increasing adoption rates..
6. There would be one fewer thing we'd need to promote.
(Just SPF, as opposed to SPF & SRS. Okay, maybe the
long-standard DSN counts as a half a thing. :-) )
Yes, for this method to work, both forwarders and recipients of forwards
must support ORCPT. However, it looks to me as if it would be easier to
convince admins to use ORCPT in forwarding than to use SRS because:
1. ORCPT is an existing, turn-key solution.
As I understand it, support already exists for ORCPT
in most MTA's already--at the very least it surely
has a far larger existing install base than SRS has.
2. ORCPT was first introduced in RFC1891, eight years ago.
For admins that *don't* already have a functioning
DSN/ORCPT installation, it should be politically easier
to promote the idea that they should upgrade/update/patch
their MTAs to support an eight-year-old standard than to
suggest that they implement a method of return-path
rewriting that's still in active development.
And then for those who still want the forged-bounce protection that SRS
provides, note that:
1. This system is no more vulnerable to forged bounces
than classic forwarding is.
2. You can still use something like SES to protect yourself
against forged bounces, if you like.
Unfortunately, there are two things I am unsure of:
1. Whether by default MTA's that support DSN tend to write
in values for ORCPT when forwarding mail.
2. Whether the ORCPT value gets overwritten at each forwarding
hop. (I have merely *assumed this is the case, but the RFCs
aren't really specific. Unfortunately sendmail doesn't log
ORCPT values, and I haven't looked at the source nor have I
used tcpdump to look at the actual data yet.)
As side note on what this could look like from a user's point of view:
======================================================================
With SPF and ORCPT checking, each individual user could decide:
1. Whether SPF checks should be done on his email.
2. Which original recipients he will accept forwards from.
One way of implementing item (2) above would be a ~/.trusted-forwarders
file, such as: (Forwarding companies would doubtless have nice web
interfaces for this, but you get the idea.)
# Accept forwards that were originally sent to and then
# forwarded by user(_at_)forwarder(_dot_)com
user(_at_)forwarder(_dot_)com
# Accept forwards that were originally sent to and then
# forwarded by anyone at any domain including and under
# my_employer.com
@*.my_employer.com
# Implicitly trust the forwarders as defined by
# a couple other sites
#
# I'm ignoring how this transfer would take place.
# I would assume a DNS-based TXT record would still
# be very efficient. (As long as there's no XML! :-) )
include:trusted-forwarders.org
include:my_employer.org
# Also trust the forwarders defined in a file some friends
# and I share:
include:~myfriend/group-trusted-forwarder-list
All in all, I think this is a much simpler way of resolving the
forwarding issue than SRS.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com