> Argh.  This is why I don't like messing with this stuff :-)
> I prefer to wait for a fire and then put it out.  However,
> gmail spamblocking Alberto is just such a fire...
>
And, my Gmail is spamblocking Sean Cody too.  His last two postings just now both went to my Gmail spam.
 
So, now both victims feel "honoured":
 
> [Alberto Abrao] I ... am honoured ...
> [Sean Cody] I’m sure more lives are enriched by filing anything by me as spam than otherwise.
 
Good humour!  And I too now feel honoured to have started one of my 2 or 3 longest ever threads here on MUUG.
 
Now, to my own further thoughts (while omitting the curses).  I would add TXT SPF record content that legitimizes as sender any and all relaying agents, like my own forwarder/fanout, the MUUG mailing list "forwarder", etc.  And remember, only one "TXT v=spf1" record is allowed, and DNS-querying parameters (everything besides IP addresses) are limited to a count of 10.  The parameters are called "mechanisms", by the way.
 
If my thoughts above aren't sensible, note that I am very weak in knowledge at this end of e-mail stuff.  My e-mail strength is at the other end, in configuring the user stuff like SMTP/POP3/IMAP settings, doing forwarding/fanout, migrating whole mail databases from one system to another system, and such.  Though I have perused a lot of e-mail headers to figure out some failures.
 
Hartmut W Sager - Tel +1-204-339-8331


On Fri, 3 Apr 2020 at 00:32, Trevor Cordes <trevor@tecnopolis.ca> wrote:
On 2020-04-02 Sean Cody wrote:
> Ultimately the signed messages get screwed up by the mailing list.
> The headers make that pretty clear and spamassassin marks the message
> ‘X-Spam: Yes’ when further below you see another instance validate
> the original receipt.

X-Spam from the MUUG server says it passes ok.  So you must mean your
local spamass is marking it as spam.

Mailman should not touch the body, and the headers that are marked
("h=") you should be able to configure to ensure they don't include any
that mailman modify.

Hmm... maybe that means Subject: should be taken out of h=.  The very
first post to the list will have [RndTbl] prepended.  Subsequent
replies shouldn't have anything prepended, I don't think.  Thinking
about it a bit, it shouldn't be the end of the world to remove Subject
as a checked header.  Ya, it's not ideal, but that only leaves the
subject for spammers to abuse, still not the body.

I'm 99% positive mailman does not change Date, To, Cc, In-Reply-To
(seems absent) and (hopefully) References.  Excluding IRT and Refs
should likewise not cause any grief.

> Would recommend disable the DKIM check in spamassassin on the mailing
> list or strip DKIM headers before wrapping and relaying the messages
> to the list.   <https://wiki.list.org/DEV/DKIM>
> https://wiki.list.org/DEV/DKIM

Like I said, MUUG spamass seems to pass DKIM just fine (on emails from
all 3 of us).  Your idea about having mailman strip the DKIM headers
sounds like the better idea, however, some sites (maybe gmail) are
sticklers for DKIM working properly to avoid getting in spamboxes.
(Yes, usually one of the methods is enough.)

I can't find a TXT DK record for abrao.net... Mine are all under
main._domainkey.*, but is "main" user-selectable?  How do the MTAs know
which TXT record to retrieve?  Is it hidden in the dk header somewhere?
I'd like to look at Alberto's DK DNS record to see what's going on
there.

Argh.  This is why I don't like messing with this stuff :-)  I prefer
to wait for a fire and then put it out.  However, gmail spamblocking
Alberto is just such a fire...

And Sean is 100% correct that most of these antispam methods are tough
to jive with mailing lists.  The creators of these things didn't think
through all the use cases.  And thus we're stuck with 3-4 different
standards, lots of the (non big-tech) players (like me and Alberto)
implementing 1 or fewer of them, and tons of real world problems.

_______________________________________________
Roundtable mailing list
Roundtable@muug.ca
https://muug.ca/mailman/listinfo/roundtable