<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#000000">> Argh.  This is why I don't like messing with this stuff :-)<br>> I prefer to wait for a fire and then put it out.  However,<br>> gmail spamblocking Alberto is just such a fire...<br>><br>And, my Gmail is spamblocking Sean Cody too.  His last two postings just now both went to my Gmail spam.<br> <br>So, now both victims feel "honoured":<br> <br>> [Alberto Abrao] I ... am honoured ...<br>> [Sean Cody] I’m sure more lives are enriched by filing anything by me as spam than otherwise.<br> <br>Good humour!  And I too now feel honoured to have started one of my 2 or 3 longest ever threads here on MUUG.<br> <br>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.<br> <br>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.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#000000"> <br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#000000"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="font-family:verdana,sans-serif"><font size="2">Hartmut W Sager - Tel +1-204-339-8331<br></font></span><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 3 Apr 2020 at 00:32, Trevor Cordes <<a href="mailto:trevor@tecnopolis.ca">trevor@tecnopolis.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-04-02 Sean Cody wrote:<br>
> Ultimately the signed messages get screwed up by the mailing list.<br>
> The headers make that pretty clear and spamassassin marks the message<br>
> ‘X-Spam: Yes’ when further below you see another instance validate<br>
> the original receipt.<br>
<br>
X-Spam from the MUUG server says it passes ok.  So you must mean your<br>
local spamass is marking it as spam.<br>
<br>
Mailman should not touch the body, and the headers that are marked<br>
("h=") you should be able to configure to ensure they don't include any<br>
that mailman modify.<br>
<br>
Hmm... maybe that means Subject: should be taken out of h=.  The very<br>
first post to the list will have [RndTbl] prepended.  Subsequent<br>
replies shouldn't have anything prepended, I don't think.  Thinking<br>
about it a bit, it shouldn't be the end of the world to remove Subject<br>
as a checked header.  Ya, it's not ideal, but that only leaves the<br>
subject for spammers to abuse, still not the body.<br>
<br>
I'm 99% positive mailman does not change Date, To, Cc, In-Reply-To<br>
(seems absent) and (hopefully) References.  Excluding IRT and Refs<br>
should likewise not cause any grief.<br>
<br>
> Would recommend disable the DKIM check in spamassassin on the mailing<br>
> list or strip DKIM headers before wrapping and relaying the messages<br>
> to the list.   <<a href="https://wiki.list.org/DEV/DKIM" rel="noreferrer" target="_blank">https://wiki.list.org/DEV/DKIM</a>><br>
> <a href="https://wiki.list.org/DEV/DKIM" rel="noreferrer" target="_blank">https://wiki.list.org/DEV/DKIM</a><br>
<br>
Like I said, MUUG spamass seems to pass DKIM just fine (on emails from<br>
all 3 of us).  Your idea about having mailman strip the DKIM headers<br>
sounds like the better idea, however, some sites (maybe gmail) are<br>
sticklers for DKIM working properly to avoid getting in spamboxes.<br>
(Yes, usually one of the methods is enough.)<br>
<br>
I can't find a TXT DK record for abrao.net... Mine are all under<br>
main._domainkey.*, but is "main" user-selectable?  How do the MTAs know<br>
which TXT record to retrieve?  Is it hidden in the dk header somewhere?<br>
I'd like to look at Alberto's DK DNS record to see what's going on<br>
there.<br>
<br>
Argh.  This is why I don't like messing with this stuff :-)  I prefer<br>
to wait for a fire and then put it out.  However, gmail spamblocking<br>
Alberto is just such a fire...<br>
<br>
And Sean is 100% correct that most of these antispam methods are tough<br>
to jive with mailing lists.  The creators of these things didn't think<br>
through all the use cases.  And thus we're stuck with 3-4 different<br>
standards, lots of the (non big-tech) players (like me and Alberto)<br>
implementing 1 or fewer of them, and tons of real world problems.<br>
<br>
_______________________________________________<br>
Roundtable mailing list<br>
<a href="mailto:Roundtable@muug.ca" target="_blank">Roundtable@muug.ca</a><br>
<a href="https://muug.ca/mailman/listinfo/roundtable" rel="noreferrer" target="_blank">https://muug.ca/mailman/listinfo/roundtable</a><br>
</blockquote></div></div>