On Thu, 2004-12-16 at 09:35 -0800, Hallam-Baker, Phillip wrote:
An RFC 822 identity is something that I as a user type into the machine.
I'd be willing to place bets that your MUA uses what you type in as
_both_ RFC2821 and RFC2822 identity in the mails you send, if you send
by SMTP.
The RFC 821 identity is about to be trashed by BATV or something like it.
That's not a problem -- and neither is VERP on mailing list traffic. The
original isn't hard to see in the result. And still the most important
thing is _rejecting_ bogus email; once the user is looking at it we've
already lost. So visibility should always be a secondary concern.
I can persuade pretty much any MUA to reveal the 822 address, the 821
address on the other hand is lost in transit and there is no way for me to
actually see it, the bits NEVER reach my MUA.
You have no Return-Path header added? That is fairly rare these days.
Since we're talking about having to modify the MUA to reliably show
these addresses, I don't think it should concern us particularly if we
also have to fix the occasional MTA which doesn't add a Return-Path:
header already.
I've never used Exchange myself but I've just asked a sufferer, and he
reports that it does (or at least can) do so.
Furthermore the signature headers &ct will be carried in the RFC 822 message
envelope. If you try to sign 821 data you are guilty of a layer violation
that will inevitably lead to a train wreck. The problems with POP3 and the
email senders are due to the failure to observe the protocol/message layer
separation that has always been present in email. In effect you are
proposing the most radical change to email imaginable.
Sorry, got distracted by watching your hands wave. Can you be more
specific?
If you want to sign the 821 data go ahead and propose an appropriate SMTP
level scheme.
That would probably be something like SES.
--
dwmw2