In <4110E7CC(_dot_)5796(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
wayne wrote in mxcomp (MARID):
http://www.ietf.org/internet-drafts/draft-schlitt-marid-spf-from-hdr-00.txt
That's the first time I see this. It's not on the page with
the MARID drafts (see <http://purl.net/xyzzy/-ietf/marid>),
it's not on <http://spf.pobox.com/rfcs.html>, IIRC it was not
published on the SPF announce list, and if it was mentioned on
the SPF-discuss list I must have missed it:
This I-D is not on the page of MARID drafts because it is not an
official MARID document.
You are correct that it wasn't announce anywhere. This I-D is part of
the "Unified-SPF" group of I-Ds that Meng et al talked about
publishing several weeks back. It was decided that that the
Unified-SPF I-Ds should be delayed until after the work from this
group had progressed a little further. Unfortunately, due to some
miscommunication, I didn't hear about the decision to delay until
after I had already submitted the Unified-SPF/From: draft.
Since only two parts of the Unified-SPF I-Ds have been published (the
marid-protocal I-D and the Unified-SPF/From: I-D), none of us have
made a big deal over the existence of the Unified-SPF/From: I-D. I
mentioned it in response to Doug's post simply to point out that his
general idea has been talked about quite a bit and, in fact, work has
already progressed on the idea of checking only the From: header and
whitelisting exceptions.
| Comments on this draft are welcome. In the interests of
| openness, before contacting the authors directly, please
| post to the spf-discuss mailing list.
The date says July 12 2004. The algorithm is incompatible with
SPF classic, therefore it cannot be used with existing v=spf1
sender policies.
The Unified-SPF/From: algorithm is not intended to replace the
SPF-classic algorithm (Unified-SPF/MAILFROM). I think that Meng, Mark
and I are all of the opinion that existing SPF records can be used
with the various Unified-SPF checks. This is really no different than
Sender ID checking existing SPF records. (Equivalent functionality to
marid-core was written up as the Unified-SPF/PRA I-D.)
| There are no changes in semantics to existing protocols
That's not true.
This line was copied from boilerplate versions of the Unified-SPF
I-Ds. I believe that what Mark meant by it is that it doesn't change
things like RFC2822 or RFC2821.
IP okay for xyzzy: SPF classic SPF/FROM-HDR
MAIL FROM:<valid(_at_)xyzzy> PASS PASS only if whitelisted
2822 From:<some(_at_)example> don't care (FAIL => test MAIL FROM)
I'm not really interested in the 1st example, because I don't
use arbitrary 2822 From headers with a SPF-protected MAIL FROM.
This is a common case for mailing lists and such. Yes, the
Unified-SPF/From: I-D requires you to whitelist mailing lists that you
have subscribed to.
IP not okay for xyzzy: SPF classic SPF/FROM-HDR
MAIL FROM:<user(_at_)MSA(_dot_)test> UNKNOWN (UNKNOWN in step 3)
2822 From:<valid(_at_)xyzzy> don't care FAIL (step 5)
But the 2nd example is real and almost the same problem as with
Sender-Id. In fact it's even worse because Sender-Id at least
allowed to use a matching Sender:<user(_at_)MSA(_dot_)test> to bypass its
2822 From:-test.
I'm not sure what exactly the problem with this is. If I understand
things correctly, someone used MSA.test to submit a message claiming
to be from valid(_at_)xyzzy, but xyzzy doesn't say that MSA.test is an ok
source for such email.
IP okay for spam(_at_)test: SPF classic SPF/FROM-HDR
MAIL FROM:<forged(_at_)xyzzy> FAIL don't care
2622 From:<spam(_at_)test> don't care PASS (step 1)
And the 3rd example is evil, SPF/FROM-HDR results in a PASS,
but the bounce for this spam is later sent to a 3rd party (?)
The idea of the Unified-SPF suite of I-Ds was that you would check any
and all identities that you want to. Your choices are
Unified-SPF/MAILFROM, Unified-SPF/HELO, Unified-SPF/PTR,
Unified-SPF/PRA and Unified-SPF/From:. If you want to protect both
the MAIL FROM and the From: header, you would need to do both
Unified-SPF/MAILFROM and either Unified-SPF/PRA or Unified-SPF/From:.
What's the purpose of step 2 spf_test(To:,IP) ? Bye, Frank
Whitelisting the To: address is something that SpamAssassin does. It
allows many emails sent through mail forwarders to be whitelisted. If
I send email to <user(_at_)forwarder(_dot_)tld>, and it gets passed onto
<user(_at_)isp(_dot_)tld), the email will be coming from an IP address
associated
with forwarder.tld. Since user(_at_)isp(_dot_)tld has been involved with the
creation and running of this forwarding relationship, they can easily
whitelist it.
Similarly, most mailing list traffic will contain the mailing list
address on the To: header.
In a real-world implementation of the Unified-SPF/From: system, much
of the needed whitelisting can be automated. For example, using the
To: header, you can determine likely HELO and MAIL FROM domains that
should be used as a fall back when someone sends email with a CC: or
BCC: to a forwarder or a mailing list. (Hmmm... I should check to see
if SpamAssassin considers CC: to be equivalent to the To: header for
their whitelisting.)
I think that Unified-SPF/MAILFROM (aka SPF-classic) is the safest
check, but people really want to also protect the From: header. As a
result you can use Unified-SPF/PRA (aka Sender ID), but this doesn't
really protect the From: header and appears to have a much higher
error rate than SPF-classic). Or you can use Unified-SPF/From: which
requires whitelisting. I strongly suspect that Unified-SPF/From: can
be made to have a much lower error rate than PRA if there is a good
interface to the whitelisting in the MUA.
-wayne