On Mon, 2004-12-20 at 19:32 -0500, John R Levine wrote:
So talk me through what happens when I resend your interesting mail to
someone else for them to read:
MAIL FROM:<dwmw2(_at_)infradead(_dot_)org>
Resent-From: dwmw2(_at_)infradead(_dot_)org
From: johnl(_at_)iecc(_dot_)com
Sender: testlist-owner(_at_)lists(_dot_)gurus(_dot_)com
If you believe 2822, you display the Resent-Sender since this message has
resent- headers. In this case there's no explicit Resent-Sender, so it
implicitly exists with the same contents as Resent-From.
And what if I prefer not to blindly believe 2822? What if I prefer to
believe only that which I see with my own eyes?
In the above case obviously it _is_ correct to display the Resent-
Sender, since it matches the MAIL FROM. The mail was sent to the list,
and then I resent it. On the other hand, if the MAIL FROM address
contained 'testlist-owner' and '@lists.gurus.com' but all the RFC2822
headers were the same, that would be because you'd sent the mail
privately to me and I'd resent it to the list:
MAIL
FROM:<prvs=testlist-owner+M2=jlevine=world.std.com/0769c31f78(_at_)lists(_dot_)gurus(_dot_)com>
Resent-From: dwmw2(_at_)infradead(_dot_)org
From: johnl(_at_)iecc(_dot_)com
Sender: testlist-owner(_at_)lists(_dot_)gurus(_dot_)com
Both of these example happen in the wild today and as far as I can tell
you can _only_ tell them apart by looking at the MAIL FROM address. You
can't reject the latter mail on the basis that the Resent-Sender's
signature isn't valid, and you can't reject the former on the basis that
the Sender's signature isn't valid. Perhaps you can just be permissive
and require that _either_ the Sender or Resent-Sender have a valid
signature?
Also, if you use BATV (you will if you get as much blowback as I do), the
MAIL FROM is more likely to be
prvs=dmmw2/0715ab4dc89a(_at_)infradead(_dot_)org(_dot_)
Of course I do something similar, although what I'm doing predates BATV.
I'm still just using SRS on my own outgoing addresses, as discussed on
the SPF-discuss list in February.
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200402/0900.html
.. and called 'Signed Envelope Sender' by Meng Weng Wong:
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200402/0901.html
Since then the term 'Signed Envelope Sender' has come to mean something
more refined, including methods for recipients verifying addresses and
including a message-digest to prevent replay attacks. I haven't really
been keeping up and haven't implemented any of that.
I realize that at this point MTAs display From: and maybe Sender:, and
nothing else unless you push the button to see all the headers. My point
is that if we're going to encourage people to display more addresses,
we're better off displaying the ones intended for people rather than the
one intended for other computers.
Even though we can't reliably identify the one which is relevant?
Yes, what you propose there is insufficient. BATV is swell, and I use it,
but it addresses a different problem. BATV addresses bounce blowback, not
mail forgery.
Yes, and you specifically asked about messages with empty MAIL FROM:<>.
BATV ensures that only people who have a message from you
can send you a bounce, but it doesn't keep those people from lying about
who they are.
Why on earth would you care about who they are? You _know_ they had the
message you sent. They're telling you they didn't deliver it. You know
your message didn't get delivered.
I don't care who runs your backup MX for you. I don't know them and I
don't need to be introduced. But if they send me a bounce to a message
which I sent, which I know is _really_ a bounce to a message I _really_
sent, why does that matter?
You still need something like DK for forward authentication.
Well, SES actually offers forward authentication too, but I'm not trying
to push SES as a replacement for DK/IIM in this forum. Just pointing out
that authentication of _bounces_ is really a separate problem, and if
we're only going to validate the latest hop rather than trying to
validate the author at all times, then we might as well do it on the
RFC2821 address.
--
dwmw2