I have a distinct feeling that I've seen this or very similar scheme
somewhere before and possibly described here within this year...
On Sat, 10 Sep 2005, David wrote:
Hi !!
just some thoughs on how to resolve the forwarding problem without
having to wait for everybody to use SRS:
- Each SPF enabled domain should add a header on every outgoing
message with the email address of the recipient, i.e:
SPF-Original-Recipient: joe(_at_)foo(_dot_)bar
SPF tries to reject mail at the RFC821 level, it'll not get to
interpreting header fields.
Adding one header field like you describe does not account for:
1. Multiple recipients
2. BCC cases where it is desirable to hide recipient address from
appearing in the email header
Also note that original recipient can already be found (supposed
to be) in Received header fields (in the "for" clause) - though
is not quite the same because Received is added by next server
in email path rather then the one that originated email (in
practice however you can usually find if recipient has changed
or not by looking at received).
- Receivers doing SPF checks, if that header is present, should
interpret it this way:
- if the email in that header is equal to the envelope recipient
then the message has not been forwarded and neutral/softfail
could be considered just fail (see problems)
- if it is not equal then the message has been forwarded and the
spf result should not be reinterpreted. Anyway it could be easy
to maintain a database relating envelope recipients and original
recipients so the system or the final recipient could know if the
emails comes or not from a trusted forwarder (assuming that each
user has a limited set of redirections to his address and that he
knows all of them)
The system you describe requires that for every user receiving forwarded
email the system maintained list of addresses where the email is being
forwarded from. That is not easy to to implement at ISP level though its
possible at the final user recipient level if checking is done at MUA
(or webmail system like gmail/hotmail). If this is not done the system
is useless as then bad guys would just have to add this new header field
with any strange address in it so that bad SPF result is not counted
against them.
- converting from softfail/neutral to fail is dangerous, it would
help to define a result (either neutral, softfail or a new one)
that means "this message does not come from an authorized server,
no other servers could send email from that domain but due to the
forwarding problem i canot give a fail result"
- when spam comes with no SPF-Original-Recipient: header there is no
way to know if the original domain servers had added it. It will help
to define a mechanism/extension so publishers could let us know if
they always add that header or not (so messages without that headers
could just be bounced)
Yes, for something like this to work special SPF record policy would also
be required. This means that in practice taking "~all" to mean "-all"
would be safe since you know that is original user's intent (and I would
recommend not bothering with "neutral" at all).
But this does appear as something that maybe of interest for SID-like MUA
checking system (most likely checking on Sender header field if special
modifier is present like I proposed before), but not necessarily SPF itself.
With MUA this would be an addition to spam filter that works like this:
1. Check for presence of new modifier and then check appropriate SPF
record against Sender header field..
2. If the result is fail or softfail the check is done to see if
original recipient address can be ascertained based on the Received
header fields' "for" clause (many if not most SUBMIT servers add
it's own origin Received and its also often added by forwarders
before the email is actually forwarded further; you'd be looking
for lowest Received that has "for" address).
3. For address from step 2 its checked to see if its the same as
final recipient address (I suppose this could be found from
top-most received "for" clause if not immediately available).
a. If its the same and SPF result is fail or softfail, then
"possible forgery" negative score is recorded for use when
deciding if email is junk or not based on results of some
other tests
b. If the address is not the same then its checked if the
address is on user's local list of forwarded addresses
and if it is, then SPF check score is 0 but if its not
found on local list then same as with b the result of
spf check would be "possible forgery" score.
While there would be some false positives, if appropriately
tuned at MUA level, this could be quite effective as part of the
overall filtering system (but not to reject email on its own).
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
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