Panic: file smtp-address.c: line 530 (smtp_address_write): assertion failed: (smtp_char_is_qpair(*p))

[Stephan Bosch]

Hi Ralf,

Op 3/2/2018 om 3:32 PM schreef Ralf Hildebrandt:
> I have an email which cannot be delivered using LMTP:
>
> Mar  2 15:26:54 mail-cbf dovecot: lmtp(backup at backup.invalid)<29736><cPd5Mi5fmVoodAAAplP5LA>: Panic: file smtp-address.c: line 530 (smtp_address_write): assertion failed: (smtp_char_is_qpair(*p))
> Mar  2 15:26:54 mail-cbf dovecot: lmtp(backup at backup.invalid)<29736><cPd5Mi5fmVoodAAAplP5LA>: Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0xc6aca) [0x7f7fb50d3aca] -> /usr/lib/dovecot/libdovecot.so.0(+0xc6bad) 

A panic like that is always a bad thing and it should be fixed. Question
is how this should be addressed.

> Using  dovecot 2:2.3.0.1-6 packages on Ubuntu 16.04
>
> The address causing the error is:
>
> From: =?utf-8?Q?Dorit_M=C3=BCller?= <d.müller at JOMEC.de>
>
> Note the "umlaut" in the email address... :)

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.

But first a few questions:

1) Who or what is sending messages like that (without the proper
capability support available at the server side)?
2) Why would an MTA accept this message? What software is doing that
(and why)?
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.
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?

Regards,

Stephan.