You did not offer wording for the document, which is what the group may need, unless the editor puts forward his wording soon.
Yes, the most important issue for forwarded mail is whether the forward was requested. Collecting this data has been repeatedly dismissed as impractical, but it is the only strategy that can work successfully. Auto-forwarding is even more problematic than mailing lists. Auto-forwarding creates reputation risk and information leakage risk to the forwarding organization, so it should be approved by sending domain administration. Auto-forwarding also complicates inbound filtering for the receiving organization, so it should at minimum require evidence that the receiving user will accept it, but in most cases should also require evidence that the receiving domain will accept it. When these arrangements are approved in advance, filtering rules can reflect those commitments, and we will not have the problem of wanted messages being blocked. However, unless forwarders take authentication seriously, forwarded mail leaves the recipient vulnerable to difficult-to-detect malicious impersonation. But these should concern the mailbox providers and the software developers, not IETF. Sadly, in the decade-plus that IETF has been trying to perfect authentication as a spam defense, the threat landscape has changed. Nearly all my incoming spam is now fully authenticated. Either the responsible domain is unrecognized and has no reputation information, or the responsible sender is hidden in the Reply-To address of a message from a service provider, while the From address matches the service provider (because of DMARC). Doug Foster On Sat, Feb 21, 2026 at 9:08 AM Tero Kivinen <[email protected]> wrote: > Douglas Foster writes: > > In operation, the trust issues have been more difficulty to resolve than > > expected. > > This is mostly because people have been trying to find a system wide > solution to this problem. I.e., trust relationship that would apply to > everybody in the recipient end of the system. > > Such trust does not exists. > > It is trivial to do when you move your trust relationship to be per > user basis. Valid email forwarding happens when the user requests it > to happen. This can be when I for example ask a email service like > iki.fi. netbsd.org or ieee.org to forward emails from there to my > final email address. > > If some random domain (like google.com or microsoft.com) starts to > forward emails to me, that is something that is unwanted, as I have > not requested it myself. > > Because of this when email is forwarded to me and ends up in my final > mailbox, I do not trust google.com, or microsoft.com ARC signatures, > but I do trust iki.fi etc ARC signatures, as I trust those services > (If I would not be trusting them to properly generate ARC signatures, > I would not ask them to forward emails to me). > > > A malicious ARC set may be disguised when it is routed through a > > trusted forwarder that adds a second ARC set which merely restates the > > fraudulent information in the first set. > > No. The trusted ARC forwarded will sign authentication information how > it saw it when it received the email. If the DKIM signature is broken > he will sign information that DKIM signature was broken. If the SPF > did not match then it will sign that SPF verification failed. > > It does not care what the earlier ARC signatures said. Same thing in > the my end system. My end system do not care that there are other ARC > signatures there are, it only cares what my trusted ARC signers saw > when they received the email. If the DKIM signature is broken now, and > was broken when iki.fi saw the email, then DKIM signature is broken. > If the DKIM signature is broken now, and was correct when iki.fi saw > the email, I can trust that (the email signature got broken most > likely because iki.fi considered email as spam and marked it so by > explictly modifying the subject). > > If the SPF checks fail now (like they will most likely do as email was > forwarded), but iki.fi says SPF checks succeeded when it received the > email I can use that information when deciding whether the > authentication was valid. > > > After an innocuous change invalidates a DKIM signature, a malicious > > downstream entity could insert malicious content to take advantage > > of the upstream trust. > > When email is forwarded by trusted forwarders, it usually takes known > path from the trusted forwarder to the final destination. For example > in case of iki.fi, it will directly send it to my email server. You > should not forward your emails through malicious downstrem entities... > Note, that the user is the one who sets those forwardings they do not > appear at random, so user can decide which path the email will take > from the trusted forwarder to final destination. > > > Overall, the ability to establish a > > reliable set of trusted ARC sources has proved very difficult, while > > the volume of trustworthy ARC sets has been low. > > Global number of trustworthy ARC signers shall be zero forever, and > should be so. > > I do trust iki.fi. There is no reason for you to trust iki.fi, so we > can never agree on globally trusted signers. > -- > [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
