On March 22, 2023 3:01:40 AM UTC, "Murray S. Kucherawy" <superu...@gmail.com> wrote: >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.
I think it relates to the largest challenge to the problem statement: what distinguishes these 'bad' messages from 'good' indirect mail flows such as mailing lists. As far as I can tell, the answer is nothing, which leaves it challenging to produce an effective protocol change which addresses replay that doesn't also have substantial side effects on non-replay traffic. Scott K _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
