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?
Thank you in advance.
Nikos.
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
On 9/23/20 6:29 AM, nikos wrote:
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
It looks like the Subject: header of the message is in Greek and is RFC2047 encoded in the iso-8859-7 character set.
For some reason, Hotmail doesn't accept this.
That happened since September 10th this year. Before, all received without problem.
This is a Hotmail (Microsoft) issue. I don't know if communicating with them would help or not.
You could change Mailman's encoding for Greek from iso-8859-7 to utf-8, but this is an involved process. You have to recode Mailman's messages/el/LC_MESSAGES/mailman.po and templates/el/* and any custom templates from iso-8859-7 to utf-8, run msgfmt to recompile messages/el/LC_MESSAGES/mailman.mo and also recode any Greek strings in the list configurations. There is a script at <https://www.msapiro.net/scripts/recode_list> (mirrored at <http://fog.ccsf.edu/~msapiro/scripts/recode_list>) that can help with this last step.
I also don't know that changing the encoding from iso-8859-7 to utf-8 will help with this Hotmail issue or not, but it might be worth a try.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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
sarantis@intracom-telecom.com writes:
/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.
No, there is no better solution for Mailman 2. The handling of email headers is done by a library supplied by Python, and that form of the charset name is in all of the ISO 8859 unibyte encodings. In Python 3/Mailman 3 we may be able to change this, but both Python 2 and Mailman 2 are end-of-life so this change won't be made there.
In theory you could also change it in Mailman, but it's risky because you'd need to check for it and then substitute this form for the original everywhere it needs to be done, and I can imagine several pathways where it might be present. If you're lucky it might be abstracted into a single function that only needs to be changed in one place, but what if not?
"iso-8859-7" with the dash is the preferred form (see https://www.iana.org/assignments/character-sets/character-sets.xhtml) so it "should not" cause problems to make this change locally. But that's not something we'd want to bet on for other folks' installations.
Steve
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
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?
Thank you Sarandis
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.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hello,
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?
Thank you Sarandis
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.
participants (5)
-
Mailman-admin -
Mark Sapiro -
nikos -
sarantis＠intracom-telecom.com -
Stephen J. Turnbull