Benny said: "At present, I DKIM sign outgoing mail, but since p=none, the recipients are unlikely to find the DKIM signatures particularly helpful."
On the contrary, it helps evaluators. A well-authenticated message might be eligible for whitelisting, and will never be blocked based on sender authentication criteria. An evaluator's options are not limited by the sender's policy position. Doug Foster Details: An incoming mail stream can be broken into these phases: - In phase 1, the message source is evaluated. "Source" is any combination of identifiers that can be used to establish a reputation. In this phase, known-bad sources are blocked. A subset of known-good sources are tracked for whitelisting (bypass most or all of the content scanning), but this is only safe if the relevant identifiers are not spoofed (i.e. authenticated). Authentication for whitelisting has nothing to do with the sender's p=policy, only with the ability to authenticate. Using DKIM as well as SPF gives you greater opportunity to be in this category, if the evaluator considers your messages to need whitelisting. (Note that for the evaluator, sender authentication is not limited to SPF and DMARC. A trusted source IP, or a trusted and forward-confirmed host name, can be sufficient for authentication.) - In phase 2, messages that were not whitelisted are subjected to content filtering. Messages with objectionable content are blocked. Objectionable content often indicates an objectionable source, so the content blocks are used to update the message source block rules. False positives are used to adjust content filtering rules or add to the source whitelisting rules. - In phase 3, sender authentication failures are considered, and may be determinative. Note that there at this point there are no known objections to the message other than the sender authentication problem. The evaluator wants to block malicious impersonation whether or not the sender has a DMARC policy. Similarly, the sender does not want to block desired messages, and there are many reasons why a critically-important message can fail sender authentication. A sender authentication failure becomes an opportunity to review. A review could lead to several outcomes - The message is unacceptable and the offending source needs to be blocked. A sender block rule is created in phase 1. - The message is acceptable but does not require whitelisting. A sender authentication exception is created for this identifier set. for use in phase 3. Content filter rules may also be added in phase 2. - Since the message passed content filtering, an acceptable message with sender authentication failure is unlikely to identify the need for a new whitelisting rule, but anything is possible. When the volume of unathenticated messages becomes overwhelming, evaluators are more likely to apply automatic (stupid) rules. So it is in everyone's interest to minimize the volume of unauthenticated messages. On Fri, Sep 17, 2021 at 12:23 PM Benny Lyne Amorsen <benny+use...@amorsen.dk> wrote: > Scott Kitterman <skl...@kitterman.com> writes: > > > Also, doing anything based on an ARC header field from anything other > > than a trusted source is a recipe for failure. I've already seen > > cases where spoofed email got accepted due to ARC from an untrusted > > source. Don't forget the limitations of ARC. > > I am not particularly worried about spoofing of domains under my > control. They are at p=none and cannot change to quarantine or reject > due to the mailing list issue. > > In the past, the stance of DMARC has been clear, saying that use cases > like mine cannot be handled by DMARC policies and therefore p=none is > the only option. p=validate offers me a chance to get on board, at least > some of the way. > > At present, I DKIM sign outgoing mail, but since p=none, the recipients > are unlikely to find the DKIM signatures particularly > helpful. > > > /Benny > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
