[conspire] Awful kludge removed from Conspire and SF-LUG lists
Rick Moen
rick at linuxmafia.com
Sat Mar 2 15:51:41 PST 2024
Quoting Ivan Sergio Borgonovo (mail at webthatworks.it):
> * 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.
More information about the conspire
mailing list