Re: Awful kludge removed from Conspire and SF-LUG lists
Rick Moen <[email protected]>
| Newsgroups | gmane.org.user-groups.linux.cabal |
|---|---|
| Organization | If you lived here, you'd be $HOME already. |
| Message-ID | <[email protected]> |
Quoting Ivan Sergio Borgonovo ([email protected]): > * you DON'T HAVE to have strict DMARK... so once you have SPF/DKIM > "supporting" DMARK shouldn't be hard. Supporting DMARK is not > mandatory but it would probably makes google happier. Probably SPF > would do. SFP: :r! dig -t txt linuxmafia.com +short "v=spf1 ip4:96.95.217.99 -all" That's been in place for more than 20 years. DMARC: :r! dig -t txt _dmarc.linuxmafia.com +short That's been in place since shortly after the Feb. 1st rollout of militant DMARC enforcement by Google / ex-Yahoo, and I covered the entire matter comprehensively, right here, at the time. The above DMARC record replaced a deliberately phony DMARC record I'd had in place, that said DMARC is terrible and that people should use my SPF record, instead. Actually, I rather liked my wording, so, for old times' sake, here it is: _dmarc IN TXT "DMARC: tragically misdesigned since 2012. Check our SPF RR, instead." According to Google's page, actually, having a real DMARC record _is_ pretty much mandatory in the sense that you're going to be punished if you don't. Yes, the Google "Email sender guidelines" published Feb. 1st claim this requirement is enforced only on "bulk senders" (domains trying to send 5,000 or more e-mails per day to Google), but it's reliably reported that they are being hardassed towards small sending operations despite claiming they won't be. Creating the real DMARC record was indeed not "hard". It took me all of 15 minutes, where 2/3 of that was triple-checking all bits. As I mentioned on-list (again, right here) when I did that, I don't like the uncertainty of finding out what the de-facto implemention effects are going to be, and I particularly dislike the ongoing barrage of "DMARC reports" in a ridiculous compressed XML format. By the way, even though my DMARC RR very clearly states to please don't send me DMARC reports no more frequently than 7 days apart, guess who ignores that and sends them to me daily? Yahoo does. If that firm hadn't been killed by its own ineptitude, I think I'd want to kill it personally. (Revenant-Yahoo is now leading a ghoulish afterlife in the hands of a private equity firm, Apollo Global Management, along with its equally ghoulish corporate sibling AOL.) [ARC headers:] > Checked there was no corresponding plesk update when emails started to > have ARC records, inferred they were doing it at the MTA level [*] Yes, I've been assuming this is MTA plumbing. It pretty much has to be. With switchover to an entirely new software build, I will consider it. I am not going to try to retrofit that to the current Exim setup. But also, to repeat yet again what I've now said several times, it appears that upgrading Mailman to a release that includes its signature DMARC mitigation makes the problem of militant DMARC/DKIM breaking mailing lists go away. Therefore, if I do that, I don't need to screw around trying to also add ARC headers -- because the problem they address will no longer arise on the mailing lists. > Debian 10 is reasonably old so there are actually some chances that > linuxmafia is not running something older. linuxmafia.com is currently stalled on an old software build. This needs to be cured by a from-scratch system redesign. I've said this before. > Probably the second factor makes much easier to understand there are > some chances that a bunch of lists with few hundreds of subscribers > may reach 5000 mailing to gmail users. A quick shirtsleeve estimate of linuxmafia.com's mailing list output daily, and non-mailing-list outbound mail suggests it is unlikely the host would be attempting 5,000 e-mails per day to GMail. _However_, as I've mentioned, it's reliably reported that Google/GMail is -- notwithstanding what is claimed on the Email Sender Guidelines (Feb. 1st) page -- enforcing at least some "bulk sender" requirements on small sites, too.