On Sat, Sep 28, 2024 at 4:25 AM Douglas Foster < [email protected]> wrote:
> We need to explicitly reject the typical implementation. Early in the > document, we observe that DMARC PASS does not mean the message is safe or > wanted. The inverse is also true and should be said at the same time: > DMARC FAIL does not mean that the message is malicious and unwanted. > DMARC provides useful probabilities, but it does not provide any > certainty. The current draft attempts to state the inverse, but the > warning is buried deep in the document and is watered down compared to the > early statement. > Doesn't Section 5.4 cover this already? DMARC detects that the “From” domain may not be the entity who is > responsible for the message, and an inspection of the message may confirm > that the message is malicious. When a message is known to be malicious, > that knowledge should feed into the evaluator’s reputation database, but > that cannot be done until the responsible actor is identified. > And this? > What all of this means is that evaluators should never use p=reject to > reject the message. Instead, DMARC feeds the reputation database, and the > database of known-bad identifiers is used to reject messages from known-bad > senders. > And this? When DMARC is used to feed the reputation system of both acceptable and > unacceptable identifiers, harm is minimal. Single messages may be delayed > by quarantine, but no legitimate message stream suffers ongoing disruption. > The problem I've always had with any sort of quarantine proposal is that it demands human review. Maybe in the world of AI, this could be automated, but there's no way Gmail or Yahoo! or Microsoft can possibly support a manual quarantine. It simply can't scale. > P=Reject is a useful clue that appropriately influences an evaluator’s > estimate of risk probability. But the only way to produce a correct > result is to convert probability to certainty by obtaining additional > information which resolves the ambiguity, and then documenting that result > in the reputation database. > If you think Section 5.4 falls short of addressing all of this, you should send proposed text ASAP. -MSK, participating
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
