From: David Woodhouse [mailto:dwmw2(_at_)infradead(_dot_)org]
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.
But my receiving MUA takes the data via MAPI.
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.
That is not the problem that people want to solve here. The problem that you
are trying to solve has already been solved by SPF its game over for RFC
2821 FROM and HELO checking, they are already off the table.
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.
Oh you mean get down in the weeds like you were complaining was necessary
for RFC 2822, nein danke.
Sorry, got distracted by watching your hands wave. Can you be
more specific?
Take the time to learn about layered protocol design. Signing the SMTP
protocol data using an RFC 822 header is a clear layer violation.