1. Who or what is sending messages like that (without the proper capability support available at the server side)?

I think that was some sort of commercial mass mailer:

List-Unsubscribe: <http://newsletter.jomec.de/rmftlp.php?cid=...>

2. Why would an MTA accept this message? What software is doing that (and why)?

Postfix. It was just in the headers, so it was not relevvant for delivery.

3. What does the envelope address look like? Do both header and envelope have that umlaut (unlikely, because Dovecot should reject that already)? Maybe this could be fixed by substituting the envelope address if it is sufficiently similar.

Envelope sender is: bounce+15396@bounce.crsend.com

4. Where does this fail actually? At some point it is trying to construct an SMTP (RFC 5321) address from the header address (RFC 5322). Do you have a GDB backtrace with proper symbols?

Don't have a backtrace yet, but since the mail is still in the queue I could try getting one.

-- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt@charite.de | https://www.charite.de

Op 3/4/2018 om 9:07 AM schreef John Fawcett:

On 03/03/18 22:10, Stephan Bosch wrote:

...

Clearly, the relevant specifications don't allow UTF-8 in the local part without email address internationalization (EAI), which Dovecot does not support nor announce yet (although that should be mended somewhat soon). My preferred fix for now would be to reject addresses like that, which would maybe still mean that this message is rejected entirely. Alternatively, that address at least needs to be skipped, ignored, or modified: all of which aren't very nice things to do. The alternative is forwarding this violation to other systems, which is seldom acceptable either.

Would accepting UTF8 local part in the From header have any negative consequences for Dovecot? If it does not I would accept it, based on the fact that it maintains greater interoperability with other systems. John

Depends on what causes the panic. I don't know that yet.

Regards,

Stephan.

I wasn't able to confirm it since I've not moved to 2.3 yet and the 2.2 code is different, but this should happen if there are characters from 0x01 to 0x1f or from 0x7f to 0xff in the local part.

Yeah, I was running 2.2.x prior to my upgrade and never encountered this.

By the way I noticed that if Postfix has SMTPUTF8 enabled, then it won't hand off messages with this content to Dovecot since Dovecot does not advertise support for SMTPUTF8. If SMTPUTF8 is unavailable or disabled then Postfix passes on those characters. I suspect that Ralph has SMTPUTF8 turned off.

Ah I see:

When a message is received with the SMTPUTF8 request, Postfix will deliver the message to a non-SMTPUTF8 SMTP or LMTP server ONLY if:

• No message header value contains UTF-8.
• The envelope sender address contains no UTF-8,
• No envelope recipient address for that specific SMTP/LMTP delivery transaction contains UTF-8.

I wonder if this will break a lot.

-- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt@charite.de | https://www.charite.de

• Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>:

...

From the code in lib-smtp/smtp-address.c function smtp_address_write, it looks as though the assertion will happen whenever there is a non ascii char that is also non qpair in the local part, ie !smtp_char_is_atext(*p) and !smtp_char_is_qpair(*p).

Could somebody please point me in the direction how to obtain a coredump here?

I found sysctl -w fs.suid_dumpable=2 but where will coredumps be written?

-- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt@charite.de | https://www.charite.de

• John Fawcett <john@voipsupport.it>:

Postfix already permitted UTF8 in message headers and local part of the address before the introduction of SMTPUTF8 and that has remained so. I don't believe turning off SMTPUTF8 in Postfix will change the behaviour in this case.

I agree.

-- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt@charite.de | https://www.charite.de

On 05/03/18 14:03, Ralf Hildebrandt wrote:

• A.L.E.C <alec@alec.pl>:

...

On 03/02/2018 03:32 PM, Ralf Hildebrandt wrote:

...

The address causing the error is:

From: =?utf-8?Q?Dorit_M=C3=BCller?= <d.müller@JOMEC.de>

Note the "umlaut" in the email address... :) This is about SMTPUTF8 (RFC6531). Looks like your only option is to disable smtputf8_enable in Postfix config. It IS already disabled.

Ralph

if you compile and enable SMTPUTF8 in Postfix the mails should bounce without getting to dovecot. That may or may not be what you want, but at least they won't stick in the queue.

John