Infrastructure

From time to time, we have errors like these with mail clients not able
to cope with the "+" sign

Which client are you using to send the mail?

Mozilla SeaMonkey 2.33.

There's no "+" sign in "users at global.libreoffice.org", which is the first address I had problems with.

It was only after having emails to that address denied that I tried reporting the problem to users+owner, but that email was also rejected with a similar message.

Hmmm... that's weird. Any chance to test with a different client
temporarily? The lists seem to work fine for others, so we need to nail
down the issue.

Well, trying from GMail webmail lead to some interesting discoveries. I've also just noticed that the "post denied" messages do include my original message, including headers, as an attachment (it says in the body "The denied message is below" but there's nothing below that - only just thought to look for attachments!).

• I send an email to libreoffice-ml.mbourne.<HashCode>.users#global.libreoffice.org@ob.0sg.net
  • <HashCode> is a hex number which has to be correct for spamgourmet to forward the mail; I've redacted it as otherwise anyone could use it to send mail to the list appearing to be from me.
• SpamGourmet sends that message on with modified headers:
  • From: libreoffice-ml.mbourne at spamgourmet.com (the address subscribed to the LibreOffice users mailing list)
  • To: users at global.libreoffice.org

Having the final headers as seen by the mailing list helps see what's going on. There, I see that the To: header seen by the list is:

To: users at global.libreoffice.org
<>

Which doesn't look right. The original from SeaMonkey is:

To: LibreOffice Users
<libreoffice-ml.mbourne.<HashCode>.users#global.libreoffice.org@ob.0sg.net>

So it looks like spamgourmet is incorrectly handling the To: header when there is a line break between name and address. I haven't had any trouble sending to the Mozilla list, also via spamgourmet, but looking at the messages arriving there I see a similar pattern; guess their list server is just a little more tolerant of this header! I don't know if the LibreOffice mailing list can be made more tolerant, but it seems the problem is with spamgourmet so I'll report to them.

Sending the following, from either SeaMonkey or GMail webmail when the address is not in the address book, works fine and gets through to the list:

To: libreoffice-ml.mbourne.<HashCode>.users#global.libreoffice.org@ob.0sg.net

As does the following, from GMail with the address from the address book:

To: LibreOffice Users <libreoffice-ml.mbourne.<HashCode>.users#global.libreoffice.org@ob.0sg.net>

While the following, from SeaMonkey with the address in the address book, is denied due to what seems to be incorrect rewriting by spamgourmet:

To: LibreOffice Users
<libreoffice-ml.mbourne.<HashCode>.users#global.libreoffice.org@ob.0sg.net>

The second line begins with a space, which seems to be removed by RedMine's rendering. I think that's a valid To: header (RFC 2822, Section 3.4) but seems to be mishandled by spamgourmet.

Guess I also have a workaround until such time as this is fixed.

Thanks!

Thanks for the detailed write-up!
Seems indeed to be a Spamgourmet-related thing - an empty RCPT TO
doesn't look proper :-)

Thanks for the detailed write-up!
Seems indeed to be a Spamgourmet-related thing - an empty RCPT TO
doesn't look proper :-)