I like this approach: if the issue is that an "expired" signature is treated as unsigned, I think we have an unacceptable level of false positives. But if the fact that a signature is valid but expired is simply another factor in the decision, I think we might be OK, keeping in mind that "x=" is purely advice to the validator. To *really* expire a signature, one has to stop publishing the key associated with the selector.
Barry On Thu, Feb 16, 2023 at 4:38 PM Scott Kitterman <ietf-d...@kitterman.com> wrote: > > > > On February 16, 2023 9:21:51 PM UTC, Michael Thomas <m...@mtcc.com> wrote: > > > >On 2/16/23 12:56 PM, Barry Leiba wrote: > >>>> Okay. What's the value for X - T that prevents this problem, but > >>>> doesn't cause DKIM signatures of "normal" mail to fail? > >>> There's not one "right" value; we're talking about distributions > >>> of timings for normal mail vs. replay, and yes, there's some > >>> overlap there. In practice I've seen many signers choose > >>> expirations in the range of 1hr to a few days. 1hr can be very > >>> good at limiting the opportunity for high volume replay, but I > >>> estimate "normal" signature breakage at that level is on the > >>> order of 0.1%. 24hr is probably effectively zero breakage, but > >>> with greater opportunity for replay. > >> I think you're way off on these numbers, especially for the 1-hour > >> case. While normal circumstances get mail delivery in less than an > >> hour, I have seen *many* cases of legitimate mail delayed by hours -- > >> sometimes quite a few hours. I would consider anything less than two > >> days to be unacceptable, and with that sort of gap you don't do much > >> to prevent a spam blast. > > > >I dunno, I would think it has to do with how much of a boost reputation is > >actually giving deliverability. For typical marketing email that's not too > >spammy maybe it doesn't make much difference? Adding signatures and a SPF > >record is pretty easy to do these days, so it's sort of a no-brainer to just > >do it. But if some small percentage with slow delivery fall through the > >cracks, how adverse is that to delivery, assuming they don't have a p=reject > >policy? That seems like it should be a pretty measurable thing for an ESP. > > > >Sounds like something that Evan might know. Actually it might well be worth > >adding that kind of estimate to the problem statement to judge how much of a > >problem it is. What we have now is very hand waving and makes it impossible > >to judge about how heroic we need to be. > > I think this highlights a key consideration that's easy to forget. > Ultimately the issue is not that a 'bad' message was delivered, but that a > 'bad' message got the benefit of whatever positive reputation was provided by > the signature. If one decides under X circumstances we will ignore a DKIM > signature for Y purposes, then the negative impact of that is far less than > that associated with rejecting the message, so we can probably tolerate more > false positives. > > Scott K > > _______________________________________________ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
