[talk] dealing with DMARC emails

[Charles Sprickman]

> On Nov 9, 2023, at 10:12 AM, George Rosamond <george at ceetonetechnology.com> wrote:
> 
> In this current era of the email cabal (goog,microsoft,etc), how are
> email admins dealing with DMARC emails.

Quick reply here, but after digging through a bunch of paid (hosted) and open source report parsers, I settled on this pairing:

https://github.com/userjack6880/Open-DMARC-Analyzer
https://github.com/userjack6880/Open-Report-Parser

Works well, developer was easy to work with on a few PostgreSQL issues...

Charles

> 
> We host our own mail, but the question applies to everyone getting DMARC
> emails even if you're stuck in the email cabal mud.
> 
> For $job, I usually just use Python dmarcreporting
> (https://pypi.org/project/DMARCReporting/) and deal from there, since
> it's a shell-based tool and I don't get XML-inspired headaches. But
> things have gotten a bit messy with more noisy outgoing sales emails,
> and I need to move beyond the manual.
> 
> And please recognize that there are more broken/misconfigured SPF and
> DMARC records out there than anyone can imagine. I wish I could post a
> DMARC email from this AM with emails sourced from a very well-known
> tech-heavy company...
> 
> The proliferation of 3rd parties, people relying or ignoring
> mass-mailing application instructions and the basic reliance on the
> email cabal for email hosting are the likely roots of the problem.
> 
> At $job we collect and parse out SPF and DMARC (when default) on a huge
> number of domains, and it's remarkable how RFC-ignorant the world is.
> Hard to believe that this internet thing works at all.
> 
> I keep thinking of building something that does the following:
> 
> * dealing with automatically grabbing the gzip/zip'd XML attachment,
> distinguishing between the 'rua' (aggregate) and 'ruf' (failure) DMARC
> emails as they arrive.
> 
> * displaying them on some static web page with internal company-wide access
> 
> * providing diagnosis in simple English so most people can figure out
> the issue if there's any "fails"
> 
> * maybe even pull in the output of SPF especially if relevant to
> remediation ("Please add $mass_spammer to you SPF")
> 
> I'm more than happy to keep stored in the filesystem, as opposed to in a
> database at this point.
> 
> How are you dealing? What other applications are worthwhile to explore?
> 
> g
> 
> PS: we need to get back to using talk@ for these routine day-to-day
> questions. talk@ was once an arena for these questions, but I think many
> have dropped this habit since many are concerned with asking "dumb
> questions" and some prospective employer saying "what a stupid question".
> 
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> https://lists.nycbug.org:8443/mailman/listinfo/talk