There was one prior answer to this. Here's another. There's a claim here that the problem statement(s) is/are too vague. I'm a little worried that tightening up the problem definition along these 20 vectors will give us such a tight problem statement that any solution is so targeted as to be of limited value. The sweet spot we're looking for probably lies somewhere in between.
Gmail's auto-formatting made a mess of the numbers as I went through this, so sorry if that confuses things. On Fri, Feb 17, 2023 at 11:11 AM Michael Thomas <m...@mtcc.com> wrote: > I've said in multiple threads that the current problem both in the charter > and the problem draft are far too vague for us to address. Here are some > from me at least: > > 1. Who are the victims? Just bulk senders? Are the bulk senders > signing using their domain? > > In my view, there are two: The receiver of the unwanted spam (that might not otherwise have been delivered), and the owner of the domain whose signature got replayed as it might now suffer a degraded reputation. > > 1. If there are different types of senders who suffer from replay > attack reputation, are the attacks using the same or different techniques > to create the signed spam? > > I haven't heard much variance in the attack technique. It's always something close to this: * send something that gets signed by a large operator to a single recipient I control * capture that signed message, assuming the signature still validates * replay it all I want from other servers > > 1. Do senders filter outbound traffic for spam? > > I think it's safe to assume that the case we're most interested in does do this, but it seems to me that irrespective of the answer, the attack is working. > > 1. Do spammers who get a piece of email signed by a sender also send > mail to target domains to see if it passes their filters? > > I would guess "yes", though perhaps not specifically as part of a replay campaign. That is, they were doing this long before anyone claimed replay was a rising problem. > > 1. What are the characteristics of the spammer wrt to the sending > domain? Are they brand new accounts or established ones? > > This one I don't have a guess about. I would say "either". Does this need to be known, or does it need to constrain the problem definition? > > 1. Do sending domains keep track of users who are sending spam in the > eyes of their filters? Do they correlate that with other characteristics of > their users such as freshness? > > Also "either". > > 1. Do senders pay any attention to the To domain? > > I can't imagine this being valuable signal, given the additional use of various other address fields. > > 1. Do receivers pay attention to the To domain(s)? > > Same. > > 1. Does the To domain spammers use remain more or less static, or do > they mutate at a high rate? > > The "To" field, or the RCPT TO(s) in the envelope? It seems like the To field (if signed) never changes, or it's whatever the spammer wants it to be if it's not signed. In the latter case, it's easy to make "To" and RCPT TO match, thwarting that check. > > 1. Can we quantify the reputation bump (or hit) on the receiver from > these spam bursts? (I'm sure the spammers know the answer to this) > > I imagine this is a property of the spam campaign itself and the response it draws, and probably varies from one receiver to the next as reputation is their varying secret sauce. > > 1. Do spammers with a replay server sign and/or set up SPF records for > their spam sending domain? > > Also "either". > > 1. Do spammers provide an unsubscribe link which is typical on normal > email blasts? If not, is that unusual and/or against the rules of the bulk > provider? If so can the sender keep track of that? > > Do we need to know this to define the problem space? > > 1. Can senders verify that opt-out links actually work especially for > new accounts? > > Same question. > > 1. Can filters be adjusted at a more fine grain in the face of > different conditions? That is, accept a higher false positive rate in > certain conditions? > > This seems to me to be part of the answer we might provide rather than part of the problem definition. > > 1. Are there receivers out there that treat an x= expired message > different than a missing or broken signature? It's ambiguous in the DKIM > text about that, I think. > > Right, DKIM doesn't require enforcement or even checking of "x=", other than if present it must be greater than the "t=" value. OpenDKIM's library will consider the signature invalid and tell you this was the reason; the consumer is free to make whatever handling decision it wants based on that. The filter is configurable. > > 1. Can receivers take advantage of the signalling of a small x= value > as also a clue that the sender is concerned about replays? > > I don't think I've ever seen such guidance documented or implemented. OpenDKIM's library would let you get that value out, I believe, but that would be pretty advanced usage. > > 1. Do receivers use things like unsigned Subject or To or other > tell-tale fields as signs of a bulk replay? > > I don't think they've ever been specifically associated with replay, but an unsigned Subject was held up even in the early DKIM days as the sort of thing about which a receiver might exercise its discretion to invalidate a signature. The Authentication-Results RFC introduced the term "acceptable to the verifier" around this sort of decision tree. > > 1. Do receivers collect and use reputation information on mailing > lists and other indirect flows that resign their messages? > > Very large ones are known to have such data. > > 1. What percent of incoming email to a mailbox is through resenders > and of that what percent resign? > > By "resign" you mean something that has signatures from two domains, correct? If so, how could one tell whether the originating operator did or did not attach one or more of them? > > 1. Do receivers keep tabs on which users are using things like > mailing lists to differentiate users who expect to get indirect mail vs > those who don't? > > The large mailbox operators might have hints about this, but I'm not sure the answer would serve to further constrain the problem statement. -MSK
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
