Seth Goodman wrote:
I agree that looking for SES0 or SRS0 with the originator and forward
domains the same is a reasonable way to detect an originator signed
envelope
address. _If_ the recipient has a need to validate the originator
address i.e. they do not use a trusted forwarder whitelist, they would
then query the SPF record for the originating domain. Presumably, the
SPF record
would
contain an exists modifier with appropriate macros to query the DNS
server and get it to validate the address. I'm not very good with SPF
macros,
but
here's an attempt at a proposal. Please feel free to improve this!
v=spf1 a mx ses:%{L}._ses.example.com -all
where ses = new modifier that says all mail is SES signed
and provides an 'exists' string to validate it;
--Roger Moser <roger_moser_spf(_at_)greenmail(_dot_)ch> wrote:
We don't need a new mechanism "ses" because
"v=spf1 a mx exists:%{S}._ses.example.com -all"
already means following:
- accept the mail if it came from our mail server
(then for sure it has a valid signed envelope sender),
- if not, check the envelope sender by using the 'exists' mechanism,
- if that fails, reject the mail.
Actually I think I see where Seth is going here. The ses: implies that we
are checking the MAIL FROM: of the original hop, not the rewritten MAIL
FROM.
I think this means checking the SES at every step, even if MAIL FROM is
rewritten to another forwarding domain. (or, stating that in terms of the
Layers post I just wrote, if you are able to validate Layer 2, that trumps
Layer 1, and the mail is considered Verified Direct.)
The problem here is that you are checking two *different* SPF records...
one for the MAIL FROM+SRS domain (which I am calling Layer 1) and one from
the From: or original MAIL FROM domain (layer 2). So it's not really so
much about the extra mechanisms we need, it's more about triggering a
second SPF check against the From: to see if you can validate it more
directly.
The difference with SES is that usually From: won't match, but SES will
always match successfully, since it is not based on IP of the current MTA.
Usually you would not want to reject based on the SPF of the From: but in
this case the domain owner is trying to tell you "Go ahead and reject based
on this"
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>