Thrilled to hear that I am not the only one objecting to DMARCbis as written.
Who uses DMARC? I conclude that there are two different kinds of evaluators:
- Those who have to be accurate, neither blocking wanted messages nor allowing malicious messages.
- Those who have freedom to use guesswork and ignore the resulting disposition errors.
Apparently some of the mailbox providers put themselves in the second category. Verizon Medial publishes p=reject, and Google's contribution to this workgroup was an insistence that the DMARCbis algorithm be fully automated. Accuracy and automation are not compatible. I consider that viewpoint out of scope.
For the rest of us, we have to be accurate. My job depends on getting business-critical messages to my users, and the survival of my company depends on my ability to ensure that ransomware does not get to my users. DMARC helps me to get there
After 15 years, it should be clear to all that DMARC has two big problems:
- Insufficient coverage, leaving lots of opportunity for malicious impersonation to go undetected, and
- Unwanted messages getting blocked when messages lose authentication in transit.
This is pretty much everything of interest to a protocol: It does not attempt to detect all threats, and it does block non-threats. I would only add that it also fails to take the right action when a true positive is detected.
Solutions to these problems were presented, and repudiated, within the workgroup.
- The WG repudiated my attempts to expand scope to detect and block all impersonation.
- The WG repudiated my conviction that the purpose of failure detection was to find the attacker responsible for malicious messages.
- The WG refused to discuss ways to detect and securely handle false positives.
What the work group really lacks is participation from a meaningful number of evaluators who are interested in using DMARC correctly. The absence of any participation from email filtering vendors is a strong indication that they either consider DMARC a complete failure or consider the IETF process a complete failure. I suspect the first, but I don't know.
Perhaps the Last Call evaluators will be willing to put this publication request on hold for two months, while I work with Jim Fenton to write a document that fixes DMARC problems instead of institutionalizing them.
Doug Foster
On Mon, Dec 2, 2024 at 5:33 PM Scott Kitterman <scott@xxxxxxxxxxxxx> wrote:
On December 1, 2024 7:47:31 PM UTC, Jim Fenton <fenton@xxxxxxxxxxxxxxx> wrote:
...
>Considering the above problems, DMARCbis is neither safe nor effective. It should not be published as a standards track document by IETF.
>
I think all of the concerns Jim expressed in his email are essentially accurate. I've deleted them for readability, since I don't think they are relevant to the response I want to provide.
If the choice were DMARC or no DMARC being used then I think it would be great to have that discussion, but that's not a choice the IESG or the IETF community gets to make. Unlike ADSP, it is very widely deployed and nothing we do will affect that.
As written, I don't think the draft is meant to be a document that provides a protocol and pushes for universal acceptance because it's so useful everyone should get on board. I think it's written to say IF you are going to do DMARC (and there are reasons you might not want to), here's a somewhat better way to approach it.
>From Jim's safe and effective criteria, I think the question should be is DMARCbis more safe/effective than RFC 7489. I think it is. Maybe not as much as I would have hoped for back when we started, but I think it's a useful step forward and captures the state of the art as well as anyone understands it.
I think it should be published as a standards track document by IETF both to improve the design of the protocol and to bring change control into the IETF so that as we learn more about how to provide the benefits of DMARC while reducing the negative side effects, it's clearly the IETF's call to do so.
Scott K
_______________________________________________
dmarc mailing list -- dmarc@xxxxxxxx
To unsubscribe send an email to dmarc-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
