As a reminder, my original post was to serve two purposes: - to announce my acquiescence to deprecating ARC, and - to start discussion about language for the "why" section of the document, since nothing had been proposed and the list had been silent for a week.
Tero says that I still don't understand how a Google ARC set caused your company to trust something that should have not have been trusted. So a better informed person needs to describe the risk correctly. - - - Responding to your other comments until the chairs shut us down for being off-topic: On the issue of forwarding, I said that solving the problem seemed like a simple administrative policy issue that needs supporting software but does not need IETF. Restating the problems for a forwarding organization when it allows any random user to forward his mail: - He may make a typo and send to the wrong address, creating a reputation problem for his domain and his hosting service. - Imperfection in the forwarding organizations filtering policy may cause the forwarding domain and hosting service to be perceived as a spam source, when the real problem is the upstream mail that did not get blocked. - The forward may leak information that is legally restricted, and the destination server is not a legally acceptable possessor of that data. - The forwarding stream may be an insider attack leaking industrial secrets to a competitor or hostile foreign country. Our organization solves these risks by preventing all off-site forwarding. I suspect that some of your employer's clients would want the same control over their employees. For the organization that receives the forwarded message, the problem is everything that created the mailing list problem: - Why are we receiving these messages indirectly instead of directly? - Can the forwarder be trusted to filter out harmful messages? - If the forwarder cannot filter out harmful messages, can the receiving organization figure out the responsible party and correctly assign reputation to each message? All of these questions are easier to answer when messages are received directly than when they are received indirectly. So the first step in solving these problems is to obtain confirmation from the recipient that the forwarded mail stream is wanted. There are also system administration policy questions, like "Do we, as your employer, want you to receive your quilting club mailing list messages on company servers during company time?" In some cases, the answer will be, "No". (This particular concern is not applicable to mailbox providers who have no authority relationship to their users.) In sum, it is advantageous for the receiving organization to have administrative controls which allow system administrators to approve or disapprove forwarding arrangements. What seems to be missing is mail store software which provides the option for administrative control over forwarding instructions. Doug Foster On Sat, Feb 21, 2026 at 8:32 PM Richard Clayton <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In message <[email protected] > il.com>, Douglas Foster <[email protected]> writes > > > Auto-forwarding creates reputation risk and information leakage risk to > >the forwarding organization, so it should be approved by sending domain > >administration. > > for large sending systems (and most smaller ones) that just isn't going > to happen... there is a proposal floating around (which may make it to > the IETF in due course) to authenticate sign-ups to newsletters &c which > will be valuable, but that is in a different space > > > Auto-forwarding also complicates inbound filtering for > >the receiving organization, > > you may think so, but in practice the receiving side of the house has no > idea whatsoever that the email will be forwarded (at any system I run or > assist with in $DAYJOB$) > > >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. > > in the DKIM2 world if the receiving user will not accept a mail the > refusal will always become known to the forwarder (who might consider > making a configuration adjustment) and it will generally also become > known to the system that sent it to the forwarder (who might also > consider whether they wish to send more email in that direction). > > >Sadly, in the decade-plus that IETF has been trying to perfect > >authentication as a spam defense, > > I don't believe authentication has anything to do with "defending" > against spam, it has a lot to do with reliably assigning reputation to > entities within the ecosystem -- and you may wish to use reputation in > your decisions about whether or not to accept messages. > > > the threat landscape has changed. > > Nearly all my incoming spam is now fully authenticated. > > one might argue that "Yahoogle" had something to do with that > > >On Sat, Feb 21, 2026 at 9:08 AM Tero Kivinen <[email protected]> wrote: > > >> Such trust does not exists. > > I am a great believer in NSA's definition of trust .. a trusted > component is one that will screw you over when it breaks. > > Hence trust is not something to aim for, but something to avoid whenever > that might be possible. > > - -- > richard writing to inform and not as company policy > > "Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM > > -----BEGIN PGP SIGNATURE----- > Version: PGPsdk version 1.7.1 > > iQA/AwUBaZpbamHfC/FfW545EQJ2dgCgqR18S545ppMx4HDE4yx30ksQV2gAni5Y > EbQdLLxQpdrnNEy62CF+IxSc > =tGkY > -----END PGP SIGNATURE----- > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
