Again, I agree with everything that I trimmed from Margaret's post.
On Sat, Apr 24, 2004 at 03:33:08PM -0400, Margaret Olson wrote:
| 2. Start work on a 2822 solution, and possibly also an MTA validation
| solution. Do not limit this solution to the confines of the current SPF
| specification.
|
| 3. Accept that the 2821 and 2822 mechanisms may be totally unrelated to one
| another. I agree that this is not desirable, given the state of the spam
| problem it behooves us to be practical.
I want to suggest that while a final solution to the 2822 mechanism may
require cryptography to be truly bulletproof, we can piggyback LMAP/2822
techniques on top of LMAP/2821 to achieve acceptable interim results. I
think the algorithm presented by Harry provides considerable value under
a number of scenarios. And hey, if it turns out to be robust against
spammer attack, we may not need to go to crypto at all.
See http://spf.pobox.com/slides/crossingbeams/0230.html
I think there's room for all three approaches, and as time passes
they'll see mainstream acceptance in order from top to bottom.
I believe that in the future, corporations that are concerned about
phishing will sign their customer communications, for the same reasons
that S/MIME and PGP users today sign all outbound mail. In that future,
sender authentication components will be beefier, and will contain a
combination of 2821 and 2822 logic. It would be nice if we could
anticipate those needs as much as possible.
Senders will want to make these kinds of statements:
1) if our domain is used in 2821, it must be from permitted servers.
2) if our domain is used in 2822, it must be signed.
If SRS fails to take off, the statements may modify to:
1) if our domain is used in 2821, it should be from permitted servers.
2) if our domain is used in 2822, it must be signed.
That version is still valuable because it lets receivers skip the
signature-checking step.
Until crypto arrives, senders may have to make do with:
3) if our domain is used in 2822, it must be from permitted servers.
If both SRS and crypto fail to take off, the statements may become:
1) if our domain is used in 2821, it should be from permitted servers, but
sometimes isn't.
2) if our domain is used in 2822, it should be signed, but sometimes isn't.
3) if our domain is used in 2822, it should be from permitted servers, but
sometimes isn't.
If the "but sometimes isn't" appears in all three statements, spammers
are guaranteed to find a way to exploit it. Therefore we need SRS,
crypto, or both.
For now, given this discussion, I am planning to put in a change to the
SPF spec that lets sender domains say things like:
When my domain is used in the 2821.mail-from, the sending mta has to
be "a mx ptr" or whatever. (This is already in the spec.)
when my domain is used in the 2822 headers, the message must be signed
with DK, s/mime, pgp, etc. (This is new.)
The syntax would be something like:
v=spf1 a mx ptr 2822.dk:_dk.domain.com -all
where the 2822.* namespace sets a different scope than the other stuff
which is 2821 by default for historical reasons.
We do need to ask ourselves whether 2821 directives should be able to
return a "fail" at MAIL FROM time, even if 2822 directives are present.
As SPF stands right now, the above example would not cause a "fail" at
MAIL FROM time, because the body needs to be examined. I think that is
the correct behaviour, but now is the time to discuss the alternatives.
Maybe we can add a meta-directive, a modifier that indicates whether the
sender domain wants 2821 and 2822 to evaluate as "or" or as "and".
"2821.2822=or" would mean:
if both 2821 and 2822 directives are present:
evaluate the 2821 directives.
if 2821 evaluation passes, accept the message.
if 2821 evaluation does not pass, test the 2822 data.
if 2822 evaluation passes, accept the message.
if 2822 evaluation does not pass, return the "milder" result of
the 2821 and 2822 tests. (If we're still in SMTP time, a 5xx
after "." would be fine.)
"2821.2822=and" would mean:
if both 2821 and 2822 directives are present:
evaluate the 2821 directives.
if 2821 evaluation fails, return an overall "fail".
if 2821 evaluation does not fail, test the 2822 data.
if 2822 evaluation passes, accept the message.
if 2822 evaluation fails, return the failure from the 2822 test.
Bounce message generation depends on the result of the 2821 test.
I believe the above algorithm maximizes expressiveness.
Domains that mostly care about phishing can publish 2822-related
directives only.
Domains that mostly care about stopping joe-jobs can publish
2821-related directives only.
Domains that care about both joe-jobs and phishing can publish 2821 and
2822 directives, with 2821.2822 set to "and".
Domains that care more about deliverability can do "2821.2822=or".
I expect most 2822-related directives to look like:
2822.pgp=<key_id>
2822.smime=...
2822.dk=_dk.%{d}
But if people want, I can add the special directive
2822.cid
to represent the algorithm from Caller-ID that looks at the From,
Sender, Resent-Sender, and Resent-From headers to identify the purported
responsible domain. Sender domains that want their receivers to use
that check can specify 2822.cid in their SPF record. Does this make
sense to anyone?