On Tue, Oct 27, 2026 at 8:01 AM Tero Kivinen <[email protected]> wrote:
> Wei Chuang writes: > > I think that position outlines the crux of the difference. While I > > understand your perspective, I think that human recipients can > > better make security decisions using the author's identity of the > > originating message than the forwarder's identity. Users typically > > have some sort of relationships with the message author, and much > > less so with the forwarders. > > It is competely other way around. Final recipient always has some kind > of relationship with the forwarding service (provided this is not > malicious forwardng), and quite often they do have relationship with > sender also, but not always. > > > The forwarder acts as a service provider, e.g., distributing > > messages or performing security scanning. > > The recipient has set this operation up himself. If he is using > forwarding service like iki.fi, he has joined the non-profit > organization providing that service. If he receives mails from mailing > lists, he has joined that mailing list himself. If he has configured > some external organiation to do security scanning for emails directed > to him, he has set this up. There is no situation where someone > randomly suddenly starts acting as a forwarded for someone. > > > The sender's identity is important so users can decide what to do > > with the message, e.g., read or delete it. > > Senders identity is important by people do get emails from unknown > senders quite often. > > > Using forwarder identities muddles that decision making. > > You are not supposed to ues forwarders identity for anything else than > ARC signature verification and as you have set up the forwarding > yourself, you know who the signer is supposed to be and if the > signature is valid you can trust that the forwarder did whatever you > asked it to do, and you can trust it has done checks it promised to do > (you did trust the forwarder enough to ask it to forward emails to > you). > > > I propose we create a lightweight "donotmodify" flag. That flag can > > be specified by the originator to tell forwarding relays with > > RECOMMENDED to not modify the message body or the Subject, To, Cc, > > or Reply-To header fields. If forwarders do so, they MUST rewrite > > the RFC5322 From header field and it MUST align with the current > > DKIM2 signature d= domain. > The intent of this flag is for traffic that is not normally expected to traverse forwarding or modifications, such as transactional traffic e.g. bills, IRS, PayPal, etc. Because users sometimes migrate from one service provider to another, the goal is not to block forwarding or modifications, but to ask parties that break the "rules" to identify themselves. By default clients will show the forwarder's identity. Of course with DKIM2, the earlier identities can be recovered if the client wishes to show those identities instead. -Wei As I said the recipient will know the forwarder, so recipient is > already able to know what kind of modification are acceptable for that > forwarder, i.e., if the recipent is using security gateway which > removes all links then recipient should accept that kind of chanegs. > If it is spam marking / filtering service adding headers and even > modifying subject (adding **SPAM** or similar) is acceptable etc. > > There is no need to rewrite RFC5322 From header. > > > This permits forwarders obligated to modify messages to continue to > > do so, but ensures they are identified. Receivers observing this > > change can still choose to reject such messages according to their > > local policy or accept them. > > Recipient should do that regardless of donotmodify flag, i.e., what is > the difference for the recipient for donotmodify flag, it still need > to verify that forwarder did what was expected and requested > regardless of that flag. Rewriting RFC5322 from header does not help > in this operation. > > > If the receiver presents the message to the user, this proposal says > > with RECOMMENDED that there be a UI notification describing the > > change. In this proposal Date and Message-id can never be rewritten > > legitimately and such modifications MUST be rejected by > > receivers. > > > > Taking that irs.gov example again. If they send with the > > "donotmodify" flag, and that traffic sent through a mailing-list, > > then. the From header field identity becomes > > [email protected] instead of [email protected]. > > The mail UI could also recognize that the forwarder who modified the > email was mailing list that user has subscribed to and modification it > has done are acceptable for mailing list and it could also then show > the indication that this email has been received through the mailing > list x. > -- > [email protected] > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
