If a mailing list can perform 100% sender authentication, it makes sense to delegate that responsibility to the list -- giving it the same treatment as I am currently giving to the best-known ESPs. Getting there requires a list that: - wants one of my users as a subscriber, - can perform 100% sender authentication, - has activated a mechanism to notify me that it can perform delegated authentication - and provides ARC data to provide correlating evidence for whatever can be correlated.
We do not currently have the policy communication mechanism, so the list cannot give me the notification that I would want. Doug On Mon, Jul 24, 2023 at 11:57 AM Neil Anuskiewicz <[email protected]> wrote: > > > On Jul 23, 2023, at 9:39 PM, Douglas Foster < > [email protected]> wrote: > > > Neil, this is about whether to block first and ask questions later: > quarantining first is safer, but not initially feasible. > > My working assumption is that essentially all evaluators release > unauthenticated traffic to their users every day. To fix the mailing list > problem, we are proposing to ask them to do so on a slightly greater scale. > > If you start on a path toward 100% authentication, the assumption is that > you cannot quarantine every unauthenticated message because you will not > have the staffing resources to work the quarantine queue in a timely > manner. So you have to do triage. > > Authentication moves: > > - Start by updating your configuration to authenticate based on the > DMARC concept instead of RFC 7489 and the sender policy. Don't waste > precious resources checking for impersonation on messages that already have > verifiable authentication. Don't allow the absence of someone else's > DMARC policy record to become a reason to put your network at risk. > > - Also consider that authentication comes in multiple forms. I > decided that a few major ESPs could be trusted to enforce client > authentication during account setup and account use, so I did not have to > repeat the process on every message from them. That does not mean that I > accept every message, because I don't. Some of them still send a lot of > unwanted traffic. But it does mean that I accept the From address as valid > without requiring an aligned DKIM signature. This move also improved my > authentication percentage. > > - Collectively, these moves will decrease the false positives in your > pool of unauthenticated messages. > > Audit moves: > > - Initially, you can start with after-the-fact audits on the most > obvious suspects. For example, find the messages that fail both sender > authentication and content filtering. These messages have a high > probability of malice, so verify the assessment and then block the sender > completely. You can actually start anywhere, because any form of sampling > will work. You have a dual goal: find the wanted-but-unauthenticated > message senders, and give them an authentication rule, while also finding > the unwanted message senders and giving them a block rule. Every > investigation moves a message source from unauthenticated to authenticated > or from unauthenticated to blocked. Since you have a finite number of > message sources, you have a finite number of investigations to complete. > > - Gradually, send an increasing volume of messages to quarantine, > based on perceived probability of fraud. Assume that this queue will > still contain wanted messages, so the quarantine volume has to be throttled > by your capacity to review all of its traffic. Wanted messages still need > to be released to users in something approximating a timely manner. > > - Over time, this process is guaranteed to reduce the volume of > unauthenticated traffic. When my SPF non-PASS rate was down to a few > messages per day, I decided that I could quarantine any SPF result other > than PASS. Some of my business partners had no SPF policy at all, so they > were quarantined and then equipped with an alternate authentication rule. > By now, virtually all of the authentication-related quarantine is unwanted > traffic. I haven't yet enforced quarantine on From verification failure, > but my FROM PASS rate is about 97%, and the remaining 3% is mostly ESPs > that have not been given special treatment. So I am focusing on content > filtering. Most of the malicious traffic comes from mailbox provider > accounts used for malicious purposes, which was sort of the goal of the > 100% authentication effort. I have to depend on content filtering to flag > those suspicious actors, and the confirmed attackers will be given a block > rule. > > Doug Foster > > On Sun, Jul 23, 2023 at 9:30 AM Neil Anuskiewicz <[email protected]> > wrote: > >> Doug, you’ve done a fine job of explaining as I groked what you said. If >> I get I think most people here got it. I’ve been busy with work and >> personal life so haven’t had as much time to lurk here. I’m curious what >> sparked your concern now? Also, isn’t it best to block first and ask >> questions later to mitigate damage while you investigate? I guess I’m >> saying the two ideas aren’t mutually exclusive. >> >> Neil >> >> > On Jul 15, 2023, at 4:27 AM, Douglas Foster < >> [email protected]> wrote: >> > >> > >> > Murray recently observed, correctly, that something went horribly wrong >> with the DMARC rollout, because it caused (continues to cause) many safe >> and wanted messages to be blocked. >> > >> > My assessment was in a recent post: >> > >> > Something about the language of RFC 7489 caused implementers to focus >> on blocking individual messages, when the appropriate use of DMARC is to >> identify and investigate potentially malicious sources. >> > >> > The "message blocking" approach violates the interests of the users it >> is intended to protect: >> > >> > - An attacker sends 10 messages that maliciously impersonates a big >> bank. With help from DMARC p=reject, the evaluator blocks them all. The >> attacker follows up with 10 messages that maliciously impersonate a major >> university. The stupid evaluator says, "p=none means no problem here". >> The message is accepted and the user is harmed because the evaluator >> learned nothing from blocking the successful attack. >> > >> > Consider a variant of the above: The attacker never impersonates a >> big bank with p=reject, it only impersonates big universities with p=none. >> The foolish evaluator blocks nothing because it only acts on domains with >> p=reject. Again, the user is harmed. >> > >> > And we know the flip side: Safe and wanted messages get blocked >> because p=reject is enforced without investigation against mailing lists >> and other traffic. >> > >> > Security theory says that ANY unauthenticated message COULD be a >> malicious impersonation, and worthy of investigation. Experience says >> that malicious impersonations are a small percentage of all unauthenticated >> messages. As a result, the appropriate response to an authentication >> failure is to investigate, not to block. >> > >> > I don't know exactly how to communicate the difference between message >> blocking and sender investigation in DMARCbis, but I sure hope that we will >> try. >> > > What you do sounds like an inbound audit process not unlike someone > who:might quarantine and continue and, as a last resort, set some bypasses > where necessary. When no more important or at least legit emails show up in > the quarantine folders for a decent chunk of time, it’s time to start > thinking about inbound enforcement. Done judiciously DMARC doesn’t have to > cause problems it can prevent them. Your process sounds like an audit > process but it’s my first day back to work after a vacation so I might be > short a few IQ points for a few days so I hope I understood you correctly. >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
