For the first time ever, I've actually seen an email to a mailing list that was somewhat "broken" by the implementation of DMARC.
This is possibly correlated to the fact that I don't belong to a lot of mailing lists, or perhaps because as we're busy rolling DMARC out ourselves, I'm more attuned to it...
I occasionally look in my spam folders. Gmail offers incredible spam filtering - very few false positives, and very few false negatives. But one gets into the habit of checking spam folders anyway!
This morning, I found an email with a red warning banner across it in my spam folder - a message (legitimately) sent from a Gmail address to a mailing list run by the country's ISP industry body.
The link at the end goes to this help page, if you're interested.
Looking at the "Show Original", we can see the message fails DMARC:
Digging in further (because I decided to send them a hopefully helpful email about what they might be able to do about this sort of thing), I noticed that the version of the mailing list software they were using was about seven years old (v2.1.14).
Whilst I'm the last person to suggest updating to the latest, greatest version of a package "just because" (critical vulnerabilities aside), running seven year old mailing list software that doesn't handle emails from @gmail.com seems a little fossilised, and it might be time for an upgrade.
As an aside, with regards to "upgrade when you must", only two weeks ago, I kept telling the person that mostly manages the school's MIS that "upgrading to a new release, when the current one isn't broken and the new one doesn't offer anything you can't live without, is a bad idea" - something I mention every time (monthly, it seems) there is a new release - and then the latest, greatest version was pulled for bad bugs... Fortunately, I try to implement at least a few weeks pause between release and installation - let others find the problems! I think they may have finally realised that occasionally, I may know some things. Unfortunately, said individual seems to be in the early parts of a curve like this or this (Dunning-Kruger, anyone?) with respects to systems administration best practices and norms and we regularly butt heads on such things. Instability in the program that basically runs all of your school administration is a bad idea. Back to our regularly scheduled programming...
This pre-dates a lot of people scratching their heads about how to manage the implications of DKIM and DMARC on mailing lists. (SPF was an earlier challenge to mailing lists, in the bronze age of the internet - around about 2003).
The specific software they are using (like many other mailing lists) is Mailman. Later versions of it add support for things that help to mitigate the (non-)delivery of messages to mailing lists from domains which implement SPF and DMARC. In Mailman, from_is_list seems to be a helpful setting, as is then munging the From: address to something at the mailing list domain. Ideally, keeping some kind of "chain of trust" alive would be quite good, and this is where ARC (Authenticated Received Chain) comes in. It's not yet an RFC, but the draft is available.
If you run mailing lists, then you might well want to take a few minutes to consider about whether or not you need to do anything with your software. If you're using Google Groups, they already seem to use ARC. There is some software available if you'd like to play with ARC.
No comments:
Post a Comment