From: Greg Connor
Sent: Monday, May 24, 2004 12:43 AM
I think we're on the same page and all is well.
I will take a quick stab at addressing one point regarding the new scheme
and then sign off for the night. (I'm not responding to all points you
made, since we're mostly in agreement :)
I'll do the same.
--Seth Goodman <sethg(_at_)GoodmanAssociates(_dot_)com> wrote:
[Regarding SES in combination with localpart macros,
exists:%{l}....]
I guess we now have to take account of the fact that SPF checks are only
done on MAIL FROM: at the first hop. At the second and subsequent hops,
we now use (RFROM -> FRED ->) DAVE parameter, the SPF check on (PRD ->)
PRA does not validate the return-path.
That is correct. The way I understand it, if the RFROM parameter
is there,
you would check that, and NOT check MAIL FROM. This is similar
to, if the
MAIL FROM is an SRS rewrite, you would normally only check the SPF record
for the forwarder's domain.
If the message has been forwarded, but there is no RFROM, we would check
the 2822 headers and try to glean who forwarded it, if any.
That is before flag day, as I understand it. After flag day, if there is no
RFROM/FRED/DAVE, we do an SPF check on MAIL FROM:. In other words, after
flag day, a forwarded message with no RFROM will be rejected because it will
not pass SPF.
<...>
The ideal case is if the SPF-aware forwarder is checking SPF on
the way in,
then if you are a customer of the forwarder, you can trust that the first
hop check has already been done. I don't know what would happen
if we had
to check the correctness of previous hops besides the current one.
If the forwarder does check SPF on incoming messages and rejects everything
but a PASS result like they're supposed to, we're golden. If they don't,
the only hop we really care about is the first one. Really, the only reason
for checking RFROM/FRED/DAVE at each hop is so that at the end of the chain,
we believe that MAIL FROM: is correct. That is verified on the first hop,
we fervently hope, and we also hope it is never altered. If we have to
check the MAIL FROM: at the end of the chain, the method is either a CBV or
the DNS equivalent to the domain in MAIL FROM: to verify the SES signature,
which we will put in anyway to avoid all forged bounce spam.
With the old SPF, trusting another party to do the SPF check was problematic
because of the leeway they had with the intermediate results of NEUTRAL,
UNKNOWN and SOFTFAIL. They didn't even _have_ to reject on FAIL. The new
SPF insists on a PASS, and that changes things quite a bit. If I understand
things right, the first hop recipient also checks the headers to make sure
that MAIL FROM: is the same as the PRA and will reject at the end of DATA if
it isn't, so we've really gained something here.
We'll have to wait to see what the draft looks like, but I would heavily
favor a MUST reject on anything but PASS rather than SHOULD reject. MUST
reject language would really give us confidence that if the forwarders are
SPF-compliant, we can fully trust the domain part of MAIL FROM:. That would
allow providers to reject mail based on the domain in MAIL FROM: without
worrying about dropping real mail. Improperly configured outgoing MTA's
will cause rejected mail, as will lack of SPF records, but I'm convinced
that is what it will take to clean up the present mess.
--
Seth Goodman