On Fri, 2004-06-04 at 06:48, Seth Goodman wrote:
Yes, we have to trust our forwarders. Realistically, most users don't have
any way of evaluating how well they do SPF checking.
Which puts most users' judgment abilities about their forwarders in the
same boat as their judgment abilities about their forwarded-to ISPs, but
that doesn't matter--we still have to decide whether we think can trust
our forwarders, and our ISPs, and by how much.
There's no real way around it.
Without PKI or other things that are very close, a break in the chain
breaks everything.
What's worse is that a
properly constructed forgery will pass an SPF-CID check at the next hop no
matter how careful the forwarder (or our own MTA) is. The forwarder doesn't
have to be a liar, just the originator. This is a problem even if there is
no forwarder, because the originator is posing as a forwarder.
No specifications you can possibly make, about what an *untrusted*
originator (or previous forwarder) must do, can help you to determine
the validity of a message given to you by a *trusted* forwarder later
on, without using more information than what the trusted forwarder can
give you by himself.
You can do your own separate queries to the purported originator, (such
as you suggest with SES), and you can do other queries about whether
some of the parties permit some of the claimed relationships, (as I
propose with my "stop the presses" email).
You can even use public key cryptography to help validate some claims
the message makes about itself--but even then you have to validate the
keys through some outside, trusted method.
But you *can't* say that because you don't trust something near the
start of the chain, that you're going to make a rule that the untrusted
something near the start of the chain has to be sure it validates
something on it's inputs, and expect that to help you trust something
the untrusted section said.
It's like passing a law saying that con artists who try to bilk people
out of their money must have their books done by reputable accountants,
so as to make sure that their schemes are financially sound for all
parties. That won't help potential victims any, because con artists
*lie*.
(BTW, all my "stop the presses" suggestion does is let header From:'s
tell you whether they permit any particular Sender:'s. It doesn't by
itself help you say whether the From was really from the From. :-) )
Anyway, all this means that your MUA can tell you what addresses are
known to be valid, at least to some extent.
Except for the case above and the case where the forwarder does less than
perfect SPF checks. Basically, we can't have much confidence in the
originating addresses unless there are no forwarders.
A forwarder doing less than perfect SPF checks is about the same as an
end-ISP doing less than perfect checks.
So we *can*, wearing our MUA hats, present to the user the latest
address that exists in the body headers that has been validated--it's
just that the address might look a bit ugly to an end user if it's been
SES or SRS wrapped.
The destination gateway MTA MUST unwrap an SES or SRS address to put in the
Return-Path: header. Those addresses should never be exposed to end users.
This is not a difficult requirement, as the destination gateway MTA is the
only one that writes the Return-Path: header.
Oops, I forgot that they'd have to know how to do it anyway. (Not that
you can really *depend* on them doing that of course--If nothing else,
none of them that currently understand SES or SRS will right now!)
Hmm, this means that the PRA check can be different than it currently
is..
Currently, after flag day, and without a SUBMITTER, MAIL FROM must be
the same as the PRA. (Asked about that on #spf last night to make
sure.)
If MTAs are expected to unwrap SES or SRS, then things can become
simpler if PRA merely needs to be equal to either the wrapped or
unwrapped MAIL FROM in that no-SUBMITTER case.
I'd suggest this change as a tweak to the new SPF.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com