From: Greg Connor
Sent: Saturday, June 12, 2004 12:38 AM
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.
Yes, that's exactly what I'm saying.
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.)
Exactly! SPF is a hop-by-hop validation (layer 1). If you can validate the
original source of a forwarded (end-to-end validation, layer 2), the
hop-by-hop validation (layer 1) is redundant. If forwarders do SPF checks
on incoming, we can trust that anything they hand us has been validated at
the source, so long as we validate their identity with SPF. In other words,
if a forwarder is on a local list of trusted forwarders (they perform SPF
test on incoming), validating the forwarder's identity (layer 1) indirectly
accomplishes originator validation (layer 2). This is a very useful
shortcut.
However, a forger can pose as a forwarder very easily. If a forwarder is
_not_ on the local list of trusted forwarders, or if there is _no_ local
list of trusted forwarders, we can't tell if he is:
i) a legitimate forwarder who does SPF on incoming,
ii) a legitimate forwarder who does not do SPF on incoming or
iii) a forger.
For cases ii) and iii), we need to validate the originator address if we
want to avoid forgery. However, unless the forwarder is on the local list
of trusted forwarders, we can't distinguish i) from ii) and iii), so we have
to originator checks whenever the forwarder is not on the local list of
trusted forwarders, _if_ we really want to avoid forgeries. Not all
originating domains will provide the means to validate originating addresses
(SES or SRS-at-the-originator signatures), but the more that do, the better
the system works. If we reach a high enough adoption threshold, we can
start to refuse mail where the forwarder is not on the local list of trusted
forwarders and the originator address can't be verified. Any mail that
comes from a forwarder that is on the local list of trusted forwarders will
be accepted, as well as any mail that comes directly from an originator that
passes SPF, regardless of the presence of originating signatures or the
ability to validate them.
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.
That's a good way to put it.
The difference with SES is that usually From: won't match,
Actually, either From: or Sender: will usually match the _unwrapped_ SES
signed address. I earlier suggested that we consider making this a
requirement, as it will accomplish layer 2 validation without the overhead
and other problems of DomainKeys. This would make SPF a _much_ stronger
proposal, IHMO.
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"
The only problem is that unless we _always_ query the SPF record for the
originating domain, we have no way of knowing that the domain owner said
that. We could require that, but it is an extra DNS query at every hop (not
really that bad). If we did that query _before_ the query for the current
sender, and the result was pass, we could skip the query for the current
sender. Another alternative is to say that a forwarder on the local list of
trusted forwarders has already validated the originator address, so we don't
have to. The only fly in the ointment here is that we have to be sure that
the forwarder also uses this same methodology when they encounter a forward
on incoming. Unless our forwarder also checks originating addresses on
incoming forwards where the incoming forwarder is not whitelisted, the
shortcut scheme falls apart. We could easily test our forwarders with some
contrived forgeries, including forged forwards, to make sure that they
reject them before whitelisting them.
Considering how easy it is to get the above forwarder audit wrong, it might
be sensible to _require_ first trying to do originator validation. What do
people think?
--
Seth Goodman