Hello

Am 23.09.20 um 15:29 schrieb nikos:

Hello list.

For some reason none of hotmail or outlook users don't receive any of our newsletter. Finally all of them auto unsubscribe.

The following is an error received form protection.outlook.com:

Remote Server returned '550 5.6.0 CAT.InvalidContent.Exception: ExchangeDataException, Decoding of header Subject failed+ADs- raw value: +AFs-Ps+AF0- +AD0-?iso8859-7?b?wer98fnz5yDF8OX05enh6t7yIOXq5N7r+-fPn8iDz9Oft?+AD0-; cannot handle content of message

That happened since September 10th this year. Before, all received without problem.

Any suggestions?

Seems you have an encoding problem in your subject fields. I assume you add something which isn't in a character set matching your List settings for default language. Therefore mailman doesn't encode it properly and sends 8-bit characters in the subject. Specifically the starting: +AFs-Ps+AF0-+AD0-

Kind regards, Christian Mack

Hello,

The problem that Nikos had reported back in 2020, happened to our mailman installation too and since there was no resolution to Nikos initial problem, i thought to send our investigation results to the same thread. So, the problem is that when someone is sending an email with a Greek subject (encoded with iso-8859-7), then Microsoft Exchange servers and Outlook.com are dropping this email with an error like the following one: Remote Server returned '550 5.6.0 CAT.InvalidContent.Exception: ExchangeDataException, Decoding of header Subject failed+ADs- raw value: +AFs-New-mlmanagerc-testlist+AF0- +AD0-?iso8859-7?b?xO/q6ezeIDcg9OXr6ere?+AD0-; cannot handle content of message with InternalId 5506148083457, InternetMessageId 8cb41556092b9f4396d7787d8616b2f6@xxx.' This happens when the client computer, which sends an email to the list, is set to encode Greek characters according to iso-8859-7. In this case, the Subject of the email is encoded like this: Subject: =?iso-8859-7?B?xO/q6ezeIDYgdGVzdA==?= The email is processed by mailman and a prefix is added in the Subject line, so it has be re-encoded. The recipients of the mailing list receive the email with the following Subject: Subject: [New-testlist] =?iso8859-7?b?xO/q6ezeIDYgdGVzdA==?=

As you can observe, the initial email was sent with iso-8859-7 but it was finally received by the mailing list's recipients as iso8859-7 (a dash is missing). Exchange server identifies the iso-8859-7 string as a valid encoding but not the iso8859-7, so it discards the email. By further investigation, it seems that the piece of code which makes this change is part of the python installation. In /usr/lib/python2.7/encodings/iso8859_7.py, in def getregentry(), there is a line: name='iso8859-7' which if it is changed to: name='iso-8859-7' then the encoding is sent correctly and the emails are received by the Exchange server. Nevertheless, i'm wondering if there is a better solution than changing the python's file, so any further thoughts are welcome. All tests have been made with Mailman 2.1.29 on Centos7 and on Ubuntu 20.04, by using the standard repos.

Sarantis Papanagnou

Thanks Steve for your reply, i'll proceed in changing the iso8859_7.py file and i'll keep my fingers crossed. Kind regards Sarantis

On 6/2/22 02:27, sarantis@intracom-telecom.com wrote:

Hello,

Sorry for getting back on the same issue but i'd like a clarification in your answer please. Does this mean that in Mailman3 this issue can be fixed in mailman's configuration without changing python libraries, or do you mean that a change is necessary in python3/mailman3 code?

What Steve was saying is this would require code changes, either in Mailman or in Python. Since Mailman 2.1 and Python 2 are both end of life, code changes won't happen. Mailman 3 and Python 3 are both still actively developed, changes are possible. Ideally, Python's library would be fixed.

sarantis@intracom-telecom.com writes:

Do you know when this change will be deployed in Mailman3 or Python3? do i need to issue a bug report in order to speed up things?

This is the "missing hyphen in iso8859-7" issue, right? To answer the question literally, at present we don't want to put this in Mailman since the suggested code change is in Python.

A bug report to Mailman is unlikely to speed things up, since we want this in Python, not in Mailman (we'd have to vendor the stdlib email package). If you file a bug with Python, I don't know whether this would be picked up for Python 3.11 (already in beta), but since it's arguably a bug (cite IANA registration, where the standard MIME charset name is "ISO-8859-7", case-insensitive) it might be. In that case there would be a release in early October of this year. Since it's a bugfix it might be picked up for backport to any versions still in maintenance.

If not, it would likely be in Python 3.12, scheduled for release in early October of 2023.

Looking a little deeper at the ISO 8859 series of encodings in cpython/Lib/encodings, *all* of them have a line of the form "name='iso8859-$PARTNO'", not just iso8859_7.py. So I don't understand why this error hasn't happen for every ISO 8859 encoding a million times a day since 2000 or whenever outlook.com came online. They're not a small provider.

I will take another look at this but it may take some time.