Skip to Content.
Sympa Menu

en - Re: [sympa-users] Message-Id

Subject: The mailing list for listmasters using Sympa

List archive

Chronological Thread  
  • From: Ruud Baart <address@concealed>
  • To: address@concealed
  • Subject: Re: [sympa-users] Message-Id
  • Date: Wed, 22 Dec 2021 12:07:01 +0100

Thank you for answering.

I think suppression of the User-Agent field  is  a short term solution. But, as you write, a real solution is more complicated.

On 21-12-2021 23:04, Matt Taggart wrote:
On 12/21/21 1:11 PM, Ruud Baart wrote:

in the postfix/amavis/spamassasin log the spam score of an email from a sympa list is like this:

X-Spam-Status: No, score=0.313 required=6.31 tests=[AWL=0.643, BAYES_00=-1.9,
    autolearn=no autolearn_force=no

The FORGED_MUA_MOZILLA score is quite high.

FORGED_MUA_MOZILLA is a meta rule that does:

__MOZILLA_MUA looks for:
  User-Agent =~ /^mozilla\b/i

__UNUSABLE_MSGID is a meta rule of:

__MOZILLA_MSGID looks for:
  MESSAGEID =~ /^<(?:[a-f\d]{8}-(?:[a-f\d]{4}-){3}[a-f\d]{12}|[A-F\d]{8}\.[A-F1-9][A-F\d]{0,7})\@\S+>$/m

It is not 100% clear for me why but I guess it has to do with the SMTP header Message-ID field combined with the User-Agent field. In this case it is something like this:

    Message-Id: <adherents-loisir-pour-tous-st-andre-le-desert.77@anonymous>

This @anonymous Message-ID is used only when a list has the anonymous sender option enabled. (and you confirm that below) Here is where it happens:

The xsequence part I think is to try to somewhat preserve the threading that MUAs and the archive will do, since those are based on Message-ID. IIRC each new message to the list that day will get a new message id, but the sequence will start over the next day.

And the message was sent with Mozilla Thunderbird

    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101

The forced sender, as defined in this list, is, as can be seen in the Sender field:


If I understand the spamassassin rule correctly the message-id field is not conform Mozilla and therefor suspected. I suppose the message-id is this way because in the list definition is defined to overwrite the from field and it has to be unique for every message.


I have read some information about this field. I assume the generated message-id is correct and unique. But perhaps the message id is not conform the recommendations as described in

The issue is the SA rule is assuming that any mail coming from a Mozilla mail client will have a particular Mozilla generated Message-ID and it's sympa changing the Message-ID that breaks this.

I propose two solutions:

1) Is it not better to generate the message id in something like


This won't work because the Message-ID would still need to match the complicated regex above.

2) An option to change the User-Agent field in a standard like User-Agent: Sympa/6.2.66 or just remove the User-Agent field.

Yes I think if sympa is going to change the Message-ID then probably it needs to change the User-Agent too.
What do you think?

Good job spotting this, we use anonymous_sender a lot and probably this is hurting the deliverability of our mails. The default scoring of FORGED_MUA_MOZILLA is:
  2.399 1.596 2.399 2.309
which is significant.

Note: there are other spamassassin FORGED_MSGID_ rules, but most seem to be looking for the same domain in both the Message-ID and From and for sympa anonymous_sender I think it should be ok. But I wonder about sympa DMARC munging of From, maybe those rules will still trigger? So maybe if sympa is going to munge From then it should also change Message-ID? But to what? There might be other SA rules worth thinking about too.

Isn't running mailing lists fun?

Archive powered by MHonArc 2.6.19+.

Top of Page