-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of
jpinkerton
Sent: Monday, December 06, 2004 12:37 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Re: RFC 2821 and responsibility for
forwarding
This might be a fix for mail-lists and forwarding which will
require the
MTA's to do nothing at all, but will have a higher overhead,
so is not a
long-term solution. My intention here is to create a "fix"
for SPF's known
problem areas, so that we can continue to promote the
publication of records
and the use of milters, while a more permanent solution to
mail-lists and
forwarding is found. Even though there is a greater overhead in this
scheme, the percentage of mail which would go through the
entire process is
probably very small, and the increase in the overhead might not be
significant.
The problem is, how do you distinguish an email that was *actually* forwarded
from one that is
*pretended* to be forwarded (by fake headers generated by the spammers MTA).
If I understand correctly, you are saying:
1) email has SPF pass (Classic-SPF)
OR
2) email has SPF fail (Classic-SPF) and try to get a pass for any number of
(possibly forged)
headers
Umm, I think this is watering down SPF too much, doesn't it become trivial for
a spammer to fake
headers such that the spam gets an spf pass from (2) when (1) fails?
And doesn't this make the "integrity" of the Mail-From no longer a certainty?
(Which, after all, is
90% of SPF-Classic)
I hope I misunderstand, and if so please clarify.
Thanks
Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
terry(_at_)greatgulfhomes(_dot_)com
Fax: (416) 441-9085
So, do the initial checks on the envelope headers as usual,
and if that
doesn't create a "pass" - check the internal, data Reply-To: , From: ,
Sender: and then the Received: headers *in reverse order*
until it either
finds a "pass" or runs out of headers - in which case it's a fail.
Like this -
Step 1.
Use the mailfrom envelope header fqdn spf record if it exists
or pass on to
the next step -
Check whether the mailfrom envelope header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the data ReplyTo: header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the data From: header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the data Sender: header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the bottom entry of the data Received: header
domain/IP/etc
is authorised
If yes - pass - If not -
Check whether the next entry up of the data Received: header
domain/IP/etc
is authorised
If yes - pass - If not -
Continue up the list of data Received: headers until there is
a match, or
proceed to next step.
Step 2.
Use the data ReplyTo: header fqdn spf record if it exists or
pass on to the
next step -
Check whether the mailfrom envelope header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the data ReplyTo: header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the data From: header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the data Sender: header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the bottom entry of the data Received: header
domain/IP/etc
is authorised
If yes - pass - If not -
Check whether the next entry up of the data Received: header
domain/IP/etc
is authorised
If yes - pass - If not -
Continue up the list of data Received: headers until there is
a match, or
proceed to next step.
Step 3.
Use the data From: header fqdn spf record if it exists or
pass on to the
next step -
Check whether the mailfrom envelope header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the data ReplyTo: header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the data From: header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the data Sender: header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the bottom entry of the data Received: header
domain/IP/etc
is authorised
If yes - pass - If not -
Check whether the next entry up of the data Received: header
domain/IP/etc
is authorised
If yes - pass - If not -
Continue up the list of data Received: headers until there is
a match, or
proceed to next step.
Step 4.
Use the data Sender: header fqdn spf record if it exists or
pass on to the
next step -
Check whether the mailfrom envelope header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the data ReplyTo: header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the data From: header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the data Sender: header domain/IP/etc is authorised
If yes - pass - If not -
Check whether the bottom entry of the data Received: header
domain/IP/etc
is authorised
If yes - pass - If not -
Check whether the next entry up of the data Received: header
domain/IP/etc
is authorised
If yes - pass - If not -
Continue up the list of data Received: headers until there is
a match, or
fail.
In reality the milter could probably shortcut some of this,
and there is a
question as to what order to check the data headers, but that
can be sorted
out later - or even made selectable by users. Passes
produced by these more
convoluted checks could be weighted according to the
recipients wishes (eg
spamassassin).
All rejects will be bounced in exactly the same way as they are at the
moment.
This scheme requires no action by anybody except the
receiver. Obviously if
the mail-list or forwarder has an spf record that is correct,
the process
will be shortened. During the early days, a mail that requires such
convoluted checking could trigger a mail to the postmaster of
the domain
causing trouble, with a short note of the problem and how to
publish his spf
record and make his service compliant.
Constructive criticism welcomed. :-/
/me hides behind the door.......
Slainte,
JohnP.
johnp(_at_)idimo(_dot_)com
ICQ 313355492
-------
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