On Fri, Nov 11, 2022 at 11:17 PM Roland Turner <roland= [email protected]> wrote:
> On 12/11/22 00:46, Barry Leiba wrote: > > 2. I send myself email from my account to my account. Of course, > free-email signs it, because it's sent from me to me: why would it > not? > 3. I take that signed message and cart it over somewhere else, sending > it out to 10,000,000 recipients through somewhere else's > infrastructure. It's legitimately signed by free-email.com. > > Straw-manning a possible mechanism: a DKIM signer is able to include > information about the number of recipients that it intended to take > responsibility for the message to be sent to[1]. A large receiver who's > seeing orders of magnitude more copies knows that something is wrong[2]. > Smaller receivers can't do much but probably aren't the major concern. A > privacy concern for email sent by individuals arises because disclosing > that there were any BCCs might be problematic, but this can be resolved by > indicating e.g. "10 or fewer" rather than providing exact numbers, and the > threshold in use can be selected by the signer to best deal with local > conditions. > > I have two concerns about the WG proposal: > > 1. Unless one or more of the larger receivers (a) has a useful tool to > help with this problem, and (b) is willing to share operational experience, > then we risk creating yet another lengthy, academic exercise (remember > ADSP?). I'd suggest that this might be enough reason by itself not to > proceed. > > See the dispatch slides here <https://datatracker.ietf.org/meeting/115/materials/slides-115-dispatch-dkim-replay-problem-and-possible-solutions> for operational experience and impact for at least Gmail and Fastmail (the presenters). See the introduction. I've heard through the grapevine that the other mailbox providers have been impacted as well. Gmail saw DKIM replay ramp up in late 2021 and early 2022 but the impact has been reduced recently perhaps due to the mitigations the industry has put in place. That said, the problem in the specification still remains. I am not aware of any tools to help with the problem, hence the request to Dispatch to do this work. I (and the authors of the other drafts) believe that DKIM replay can be detected via some of the characteristics that the spammers exploit (see concepts I posted earlier around Nov 11, 2022, 2:18 PM) but the current email authentication protocols don't look for that. -Wei > > 1. How is any possible "break the SMTP/message separation" solution > handled? Does the possibility of doing so need to be expressed explicitly > at this point? Does merely doing so induce additional bureaucratic hurdles? > Does failing to do so tie the WG's hands behind its back? > > - Roland > > > 1: a field in the signature, a message header included in the signed set, > etc. > > 2: whether the signer was lying or some other party is improperly > amplifying is outside what this mechanism could determine, certainly, but > it seems like a useful datum > > > _______________________________________________ > Ietf-dkim mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-dkim >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
