On Mon, Apr 21, 2025 at 9:34 PM Dave Crocker <[email protected]> wrote:
> On 4/21/2025 11:51 PM, Richard Clayton wrote: > > I think you may have overlooked some aspects of what is needed to make a > difference to the current situation. > > Your design records and signs the RCPT TO of the original email and > insists that there is only one recipient per email -- so far so good. > > However, you do not capture whether an intermediate system has > intentionally replayed the message (and what their identity might be). > > Richard, excluding things that are out of scope is not 'missing' them. > > My spec seeks only to deal with detecting Replay. It does that. > > If a preserved DKIM signature validates, but the recipient address does > not match, the message has been replayed. > > If an intermediary such as an alumni forwarder, wants to retain the > signature but change the RCPT-TO and to mark that action in a fashion that > permits later evaluation, that is a separate requirement. (And what I > might have missed is a clear requirements statement for needing this; so > please do point us at it.) > > It -- and other functions -- well well might be worthy to pursue, but they > are separate. > I think supporting forwarding is an essential requirement for this specification to be successful. First from a working group perspective, part of the motivation for formation of the working group was to better authenticate mailing lists such as those used by the IETF. Second, when I look at Gmail data (and sharing in broad brush strokes on this public list), I also see the need to support forwarding. There is a large difference in behavior between consumer and enterprise. For enterprise, we can see that a little under half of the messages have some sort of forwarding through one or more MTAs that's not the originator nor the receiver hence a substantial portion of traffic. There is a quick drop off in messages that are forwarded through multiple forwarding MTAs but there is a long tail of deep forwarding depth. Likely there is a proliferation of security and compliance gateway services that cause this. On the consumer side, roughly 9 out of 10 are "directly" sent email i.e. only the originator and receiving MTAs with a single SMTP transaction. While there is forwarding it is smaller in number, and that might reasonably indicate a lower need to support forwarding for consumers. However I think that there is a deeper story around forwarding and deliverability for consumers. Take the alumni forwarder scenario mentioned above. I've seen anecdotal reports that forwarding through alumni services no longer works due to deliverability and abuse problems as described here <https://alumni.harvard.edu/sites/default/files/2022-07/Email%20Forwarding%20FAQ%20for%20Volunteers.pdf> at Harvard. l don't know exactly what happened with Harvard's alumni services, but I wonder if such forwarding is collateral damage from the existing protections that were put in place back when there were large DKIM replay campaigns in 2021-2023. Note the 2022 timestamp in the URL. Those mitigations exist because DKIM does not have an intrinsic anti-replay mechanism despite it being a known issue at the time the RFC was written. My worry is that a similar issue coming from this proposed technique, that it won't help distinguish benign forwarding from replay. Another worry is that this lower fraction of forwarded email may represent how the consumer ecosystem has evolved to. One reason why enterprise email can support that much larger fraction of traffic is that the mail provider has a much closer relationship with the enterprise that enables authentication of forwarded mail traffic. I would point out that the proposal in draft-gondwana-dkim2-motivation <https://www.ietf.org/archive/id/draft-gondwana-dkim2-motivation-02.html> outlines a technique with strong support for forwarded flows i.e. can authenticate mail going through such flows. -Wei
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
