> On Nov 20, 2022, at 6:01 PM, Murray S. Kucherawy <superu...@gmail.com> wrote:
>
>
>
> On Sun, Nov 20, 2022, 11:08 Dave Crocker <d...@dcrocker.net
> <mailto:d...@dcrocker.net>> wrote:
>> Seriously. DKIM is intended as a transit-time mechanism. When delivery
>> occurs, transit is done. So DKIM has done its job and can (safely?) be
>> removed.
>
>
> One of the informational RFCs the original working group produced discussed
> this. A reason (maybe the reason) the envelope was not included in the signed
> content was so that the signature could survive without an envelope, meaning
> it could be retrieved from a mailbox and re-verified.
>
> I don't know, though, if anyone does this regularly, but it's been shown to
> be useful in some circumstances.
My input would be since UUCP days, the importer stripped the “From
return-address“ header (note no colon) once the final destination was
determined (local user existed, bounce was no longer necessary).
With SMTP, this evolved to a "Return-Path:” header and the same plug and play
stripping action occurred. It is the reason the MUA could never rely on the
“From “ or “Return-Path:” header existing when the mail was picked up, and why
DKIM doe not recommend hash binding the Return-Path header to the signature.
Side note: early mail systems had a RFC822 to Internal, Proprietary fixed
header structure mail format transformations, only the minimal headers were
read like;
From
To
Subject:
Date:
And only for replies:
Reply-to:
In short, when the MDA is reached, nothing else matters and all else is
overhead.
With the bigger ESPs now beginning to honor strong SPF and/or DKIM Policy
protocol models, to resolve the many indirect path mail issues, the
Receiver/Router needs to be fully aware of the incoming SPF protected and/or
DKIM-signed message w/o a policy wrapper, i.e. DMARC. Authorized modifications
are needed which may include removing/stripping overhead headers that attempt
to keep mail path processing change history and be a problem at the ESP.
The Authorized mail processor/router that has one goal - properly deliver the
mail to the MDA or make it available for pick up (pop) or reading (imap, web) -
Different MUAs.
—
HLS
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
