On Mon, Aug 7, 2023, at 3:42 AM, Alessandro Vesely wrote:
> On Sun 06/Aug/2023 18:07:15 +0000 Jesse Thompson wrote:
> > On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote:
> >>> [...]
> >>>
> >> The replay attackers aren’t sending what we commonly think of as spam
> >> through the signers - as the message is sent to one recipient (not
> >> bulk) and it is opt-in (that recipient wants and has asked for the
> >> mail). >
> > This is accurate from my observation. It takes only a single message which
> > evades content filters, and the attacker is the first recipient, who will
> > not report it as abuse.
> >
> > Which is why an earlier "just don't send spam" comment seemed to be
> > borderline FUSSP rhetoric. If the message isn't detected by the receiver
> > (who has the most visibility into the type of mail its users want to
> > receive) then how can a sender be held to a higher standard of detection
> > with less visibility?
>
>
> Good question! They could implement RFC 7073 to exchange information based
> on, say, the RFC5322.From field of the messages.
>
> Let me contrast that idea with a small mailbox provider's POV. Stock IMAP
> server packages provide no tools to reckon users' liking of messages.
> Reporting messages as spam also needs non-standard extensions. (There is a
> proposal to signal basic reaction to a message, RFC 9078, but it's not
> implemented).
I'll need to read up on these.
> > The reputation they are stealing is that of the DKIM domain(s) associated
> > with the signatures on the message (whether they are aligned to the
> > rfc5322.From or not). So, adding more signatures to convey more fidelity
> > would seemingly help solve the problem because receivers could better
> > fingerprint good patterns from bad patterns. But replayers could just
> > remove the higher fidelity signatures.
> >
> > To solve that, I think we need Mandatory Tags for DKIM Signatures [1] 3.3.
> > Forward signature (!fs) tag.
>
>
> That would imply you know in advance that a message is going to be
> replayed. Having that knowledge, like when you send to a mailing list, you
> can require that the replayer's signature be also present. It wouldn't
> suit the problem at hand.
Isn't the issue that any message signed by an intermediary or ESP can
potentially be replayed?
Similar to what Emmanuel is saying about detecting SPF/DKIM zone misalignment,
the solution to DKIM replay is for receivers to maintain some state and feed it
into bespoke replay detection algorithms. If all receivers can maintain this
kind of state, then there's nothing senders need to do, I suppose? Given that
*normally* all of the messages we emit have unique message-ids, receivers can
just limit the amount of duplicative message-ids they accept from us. Assuming
they know the situations in which message-ids would not be unique. That's
another thing that maybe needs to be communicated somehow as "this is normal in
this situation".
I am suggesting that chained DKIM keys would be a way for receivers to
fingerprint different message streams to build models of what is normal vs
abnormal.
Jesse
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
