At 08:06 AM 11/1/2004 +0000, David Woodhouse wrote:
On Mon, 2004-11-01 at 04:07 +0000, John Levine wrote:
Well, yeah. We've hashed over this a million times. There are
plausible arguments in favor of both 2821 and 2822 addresses, but I
was under the impression that the consensus here was that we're
signing 2822 addresses.
I was under the impression it was still a bit undecided. And the only
coherent argument I've seen for RFC2822 addresses is the visibility
thereof -- which I increasingly believe to be a bogus argument. Did I
miss other reasons why we might want to use RFC2822 addresses?
The meaning of 2821 envelope-from isn't appropriate. It's a return address, a
place to send bounces, which isn't necessarily the origin of the message.
Suppose example Systems, Inc. (example.com) contracted with example2.com to
manage its benefits program. Example2.com wants to send mail as
benefits(_at_)example(_dot_)com to example's employees, but wants to direct any
bounces to themselves, so the 2821 envelope-from is
bounces(_at_)example2(_dot_)com(_dot_)
What the recipient is interested in knowing is whether the message was indeed
on behalf of example.com. They may not even know that their benefits program
is outsourced, nor to whom, so a signature from some unknown domain really
doesn't add any value. The only meaningful signature is one that matches up
with the 2822 From, or at least something in that domain.
[As you might be able to guess, I just got a message from outside telling me to
log into some website to update my benefits selections for next year, and it
looked vaguely like a phishing attack, except that it directed me to internal
URLs.]
Another problem is that 2821 Envelope-from addresses often direct the bounce to
a different address to aid in tracking invalid addresses and associating them
with messages sent. Some of the frequent-flier mail I get does this. The 2821
envelope-from is usually within the same domain as 2822 From, so this becomes
an issue only with per-user keying (which to me still seems fairly
significant). Similarly, mechanisms like BATV that manipulate 2821 addresses
to control acceptance of bounces would complicate the per-user keying situation
considerably.
-Jim