On Mon, 14 Jun 2004, Seth Goodman wrote:
SES (or VERP or SRS) does turn plain email addresses into return-only
addresses for use only in the return-path (or RCPT TO: for null-sender
messages). Similarly, if all outgoing email is SES signed, then all plain
email addresses become destination-only email addresses for use in RCPT TO:
for non-null-sender messages, To:, From:, Sender: and Reply-To:. I think
this accomplishes the separation of address usage that you suggest.
Exactly.
Therefore a system that signs the envelope return paths of outgoing
messages should not also sign the Sender: header, and recipient systems
should not assume that the PRA is the same as the return path, and if
you're really keen on callout verification you should verify addresses in
the message header using the call-forward form not the call-back form.
This is where I'm confused.
I think I was being too terse again :-) Your long description agrees with
my understanding of the current state of SPF/CID.
If the system works, the end result must be that the recipient either has
good reason to trust the return-path or reject the message. Here is where
my original proposal comes in. Once the recipient trusts the return-path, I
proposed to "unwrap" the signed return-path address (if signed) and make
sure that it either matches Sender:, if that exists, or From:, if Sender:
does not exist. This will verify the key fields visible to the user and do
so at extremely low cost.
I think this is a useful idea, but it needs some elaboration. In
particular, remember that the usual way for a message to be re-sent by an
MUA involves adding Resent-*: headers and submitting the new message such
that its return path refers to the re-sender, not the original sender.
i.e. you need to use the PRA algorithm to work out which header to compare
with the de-signed return path. For original messages, compare with the
Sender: or From: and for re-sent messages compare with Resent-Sender: or
Resent-From:.
Note that the requirement in the MARID draft that forwarding MTAs add a
Resent-From: header conflicts with these existing semantics (because the
return path remains the same rather than agreeing with the Resent-*:
headers) as well as requiring a lot of software to be changed (in which
respect it's as bad as SRS).
My (rather more (too?) heavy-weight) suggestion for solving the header
spoofing problem was to add shadow headers which would contain signed
versions of the addresses in the standard headers, e.g. Verify-From:
would contain a signed version of the From: address which could be checked
using CBV.
Could you explain the use of call-forward verification?
This is mostly useful for border MTAs which have a limited knowledge of
the valid addresses at MTAs further inside the organization. For example,
the central email servers for the University of Cambridge are the MXes for
many subdomains (including the Computer Laboratory) but they do not have a
list of valid addresses @cl.cam.ac.uk. The MX machines can pre-check
addresses at SMTP time by doing a call-forward to verify them on the CL's
MTA. A call-forward uses a non-null MAIL FROM, either a fixed address such
as postmaster@ the MX, or the MAIL FROM of the original message. The
former has the advantage that the MX's call-forward cache is smaller
(since it doesn't contain sender/recipient pairs). The latter has the
advantages that the target MTA can more usefully blacklist sender
addresses, and the MX doesn't need to have different callout logic for
verifying bounce and non-bounce recipients.
Call-backs and call-forwards are collectively called callouts.
--
Tony Finch <dot(_at_)dotat(_dot_)at> http://dotat.at/