----- Original Message -----
From: <terry(_at_)ashtonwoodshomes(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Monday, December 06, 2004 6:57 PM
Subject: RE: [spf-discuss] Re: RFC 2821 and responsibility for forwarding
-----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
Not just any number of the possibly forged headers, but selected according
to the receivers policy. I am creating RPF here - Receivers Policy
Framework, to solve SPF's problem with mail-lists and forwarding, and it's
up to the receivers to decide how far to take the checking 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?
So - the concept appears to be technically possible, but there are concerns
over how it should work.
Well - as I mentioned, this is *not* SPF. SPF deals with publishing
records for others to use as they see fit.
This is RPF - a Receivers Policy Framework, and is something which people
can adjust to their taste - in the same way as you can adjust the settings
in Spamassassin. The intention is to allow people to use SPF records
without breaking anything and in a slightly more realistic way than certain
others who are using them ;-) I am no software writer, so I'll leave it to
others to decide how to implement it, but a patch on existing software with
adjustable settings and which could be removed later would be ideal.
And doesn't this make the "integrity" of the Mail-From no longer a
certainty? (Which, after all, is
90% of SPF-Classic)
Yes - but a guideline of how to solve mail-lists and forwarding problems for
now would be better than the utter confusion which reigns at the moment.
I hope I misunderstand, and if so please clarify.
Not at all - you're absolutely right, and the role of SPF will always be to
check the non-forgable envelope information for a highly authorotative
result.
What I am doing is trying to create a solution to a problem which is
continuously thrown at us, and is doing SPF some considerable harm. My
proposal is not perfect at all, but with suitable adjusting in different
receivers environments would probably solve a good proportion of their
problems.
Mail checked between possibly forged headers information would have to be
tagged as "possibly spam" or "possibly not ham" or whatever the receiver
wants. Such tagging could be added into the subject line. The tagging
could even include the check which passed the mail, by domain's spf record
and the header found authentic. This could be added to the foot of the
body. Spamassassin could be used to do this, or it could be a feature of
the RPF "patch".
As I see it, people *want* to have a solution, and will tolerate such things
until someone gets around to sorting out how mail-lists and forwarders
should operate, and then gets them all to comply. Spf on it's own will work
in all situations eventually, but it's going to be a gradual process, as any
innovation always is. In the meantime, we need some "fixes" for situations
that exist in the real world.
Don't let this proposal make you think I want to "water down" SPF. Far
from it -- as soon as the mail-lists and forwarders problems are resolved by
a better means, trash this method. :-)
Slainte,
JohnP.
johnp(_at_)idimo(_dot_)com
ICQ 313355492