KPN voicemail en NULL characters

[Paul van der Vlis]

Hallo,

Voicemailberichten van de KPN komen niet aan op mijn mailserver met
Cyrus IMAP omdat ze NUL characters bevatten. Tenminste dat zegt mijn
mailserver.

RFC3501 is er best wel duidelijk in dat dat niet mag en mijn mailserver
heeft geen optie om ze toch maar te accepteren, voor zover ik weet.

Hmm.

Groet,
Paul


De foutmelding zegt:
----
554 5.6.0 Message contains NUL characters (in reply to end of DATA command)
----

Uit RFC3501:
------
4.3.1. 8-bit and Binary Strings

8-bit textual and binary mail is supported through the use of a
[MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY
transmit 8-bit or multi-octet characters in literals, but SHOULD do
so only when the [CHARSET] is identified.

Although a BINARY body encoding is defined, unencoded binary strings
are not permitted. A "binary string" is any string with NUL
characters. Implementations MUST encode binary data into a textual
form, such as BASE64, before transmitting the data. A string with an
excessive amount of CTL characters MAY also be considered to be
binary.
------



--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl

[Coen]

On 21-5-2022 22:18, Paul van der Vlis wrote:
> Hallo,
>
> Voicemailberichten van de KPN komen niet aan op mijn mailserver met
> Cyrus IMAP omdat ze NUL characters bevatten. Tenminste dat zegt mijn
> mailserver.
>
> RFC3501 is er best wel duidelijk in dat dat niet mag en mijn mailserver
> heeft geen optie om ze toch maar te accepteren, voor zover ik weet.

Die RFC gaat over IMAP.
En als je zegt dat berichten niet aankomen dan gaat het neem ik aan over
SMTP?

[Paul van der Vlis]

Op 21-05-2022 om 23:39 schreef Coen:

Postfix (=SMTP) neemt ze netjes aan, maar de IMAP server (Cyrus IMAP)
weigert ze:
----
May 21 14:10:34 sigmund postfix/lmtp[29862]: E5D0C2041C:
to=<x...@mail.vandervlis.nl>,
relay=mail.vandervlis.nl[/var/run/cyrus/socket/lmtp], delay=0.19,
delays=0.14/0.02/0.03/0.01, dsn=5.6.0, status=bounced (host
mail.vandervlis.nl[/var/run/cyrus/socket/lmtp] said: 554 5.6.0 Message
contains NUL characters (in reply to end of DATA command))
----

Ik heb hier ondertussen een bericht. Maar hoe zoek ik daarin nu naar
zo'n NUL character om het zeker te weten?

Groet,
Paul

[Rob van der Putten]

Hoi

Als je het ergens in een filetje hebt, xxd en dan grep lijkt me.


Vr.Gr,
Rob
--
Google search is unreliable
http://www.sput.nl/internet/google.html

[Paul van der Vlis]

Op 22-05-2022 om 09:46 schreef Rob van der Putten:

Hoe wordt zo'n NUL character dan weergegeven in xxd?

[Rob van der Putten]

Hoi

On 22/05/2022 10:38, Paul van der Vlis wrote:

> Op 22-05-2022 om 09:46 schreef Rob van der Putten:
>> On 22/05/2022 00:09, Paul van der Vlis wrote:
>
>>> Ik heb hier ondertussen een bericht. Maar hoe zoek ik daarin nu naar
>>> zo'n NUL character om het zeker te weten?
>>
>> Als je het ergens in een filetje hebt, xxd en dan grep lijkt me.
>
> Hoe wordt zo'n NUL character dan weergegeven in xxd?

Standaard " 00" of "00 ".
Met '-p' is het wat kaler en is dus elke "00" een NULL byte.

[Rob]

Paul van der Vlis <pa...@vandervlis.nl> wrote:
> Op 22-05-2022 om 09:46 schreef Rob van der Putten:
>> On 22/05/2022 00:09, Paul van der Vlis wrote:
>
>>> Ik heb hier ondertussen een bericht. Maar hoe zoek ik daarin nu naar
>>> zo'n NUL character om het zeker te weten?
>>
>> Als je het ergens in een filetje hebt, xxd en dan grep lijkt me.
>
> Hoe wordt zo'n NUL character dan weergegeven in xxd?

00

[Rob]

Paul van der Vlis <pa...@vandervlis.nl> wrote:

> Hallo,
>
> Voicemailberichten van de KPN komen niet aan op mijn mailserver met
> Cyrus IMAP omdat ze NUL characters bevatten. Tenminste dat zegt mijn
> mailserver.

Hoe ziet zo'n bericht er dan uit? Is het "voice" deel van het bericht
niet mime-encoded dan? (zoals normaal gesproken ieder attachment)

[Rob van der Putten]

Hoi

On 22/05/2022 10:51, Rob van der Putten wrote:

> On 22/05/2022 10:38, Paul van der Vlis wrote:
>
>> Op 22-05-2022 om 09:46 schreef Rob van der Putten:
>>> On 22/05/2022 00:09, Paul van der Vlis wrote:
>>
>>>> Ik heb hier ondertussen een bericht. Maar hoe zoek ik daarin nu naar
>>>> zo'n NUL character om het zeker te weten?
>>>
>>> Als je het ergens in een filetje hebt, xxd en dan grep lijkt me.
>>
>> Hoe wordt zo'n NUL character dan weergegeven in xxd?
>
> Standaard " 00" of "00 ".
> Met '-p' is het wat kaler en is dus elke "00" een NULL byte.

Ik bedenk me net dat dit oncorrect is.
Immers X00X waarin X geen NULL matcht dan ook.

[Rob]

Rob van der Putten <r...@sput.nl> wrote:
> Hoi
>
>
> On 22/05/2022 10:51, Rob van der Putten wrote:
>
>> On 22/05/2022 10:38, Paul van der Vlis wrote:
>>
>>> Op 22-05-2022 om 09:46 schreef Rob van der Putten:
>>>> On 22/05/2022 00:09, Paul van der Vlis wrote:
>>>
>>>>> Ik heb hier ondertussen een bericht. Maar hoe zoek ik daarin nu naar
>>>>> zo'n NUL character om het zeker te weten?
>>>>
>>>> Als je het ergens in een filetje hebt, xxd en dan grep lijkt me.
>>>
>>> Hoe wordt zo'n NUL character dan weergegeven in xxd?
>>
>> Standaard " 00" of "00 ".
>> Met '-p' is het wat kaler en is dus elke "00" een NULL byte.
>
> Ik bedenk me net dat dit oncorrect is.
> Immers X00X waarin X geen NULL matcht dan ook.

Ik zou de optie -g1 mee geven dan wordt het allemaal veel gemakkelijker.

[Miquel van Smoorenburg]

In article <t6bnut$r7r$1...@dont-email.me>,

Paul van der Vlis <pa...@vandervlis.nl> wrote:

>Op 21-05-2022 om 23:39 schreef Coen:

>Postfix (=SMTP) neemt ze netjes aan, maar de IMAP server (Cyrus IMAP)
>weigert ze:
>----
>May 21 14:10:34 sigmund postfix/lmtp[29862]: E5D0C2041C:
>to=<x...@mail.vandervlis.nl>,
>relay=mail.vandervlis.nl[/var/run/cyrus/socket/lmtp], delay=0.19,
>delays=0.14/0.02/0.03/0.01, dsn=5.6.0, status=bounced (host
>mail.vandervlis.nl[/var/run/cyrus/socket/lmtp] said: 554 5.6.0 Message
>contains NUL characters (in reply to end of DATA command))

Als Cyrus IMAP geen NUL characters wil accepteren maar via LMTP wel
zegt dat er 8BITMIME support is, dan is dat een bug in Cyrus.

Als je googlet op deze melding zal je zien dat je lang de enige
niet bent met dit probleem.

De oplossing is 8BITMIME support uitzetten in Cyrus IMAP zodat Postfix
dat ook niet probeert. Ik weet niet of Postfix actief aan
MIME 8bit -> 7bit recoding doet (zou wel moeten!) - indien niet,
dan moet je maar 8BITMIME support in Postfix uitzetten.

Mike.

[Rob van der Putten]

Hoi

Heel fijn!

[Paul van der Vlis]

Op 22-05-2022 om 10:54 schreef Rob:

Zoiets:

<headers>

--MM3-12345-789
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Je hebt een nieuwe voicemail ontvangen van 06xxxxxxx op 21/05/2022 om
22:51:35 uur. Het bericht duurt 9 seconden.<C0><80>

--MM3-12345-789
Content-Type: audio/mpeg
Content-Disposition:attachment; filename= "voicemail.mp3"
Content-Transfer-Encoding:base64

//uQRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA (....)
--MM3-12345-789--

Groet,
Paul

[Paul van der Vlis]

Op 22-05-2022 om 10:51 schreef Rob van der Putten:

> Hoi
>
>
> On 22/05/2022 10:38, Paul van der Vlis wrote:
>
>> Op 22-05-2022 om 09:46 schreef Rob van der Putten:
>>> On 22/05/2022 00:09, Paul van der Vlis wrote:
>>
>>>> Ik heb hier ondertussen een bericht. Maar hoe zoek ik daarin nu naar
>>>> zo'n NUL character om het zeker te weten?
>>>
>>> Als je het ergens in een filetje hebt, xxd en dan grep lijkt me.
>>
>> Hoe wordt zo'n NUL character dan weergegeven in xxd?
>
> Standaard " 00" of "00 ".
> Met '-p' is het wat kaler en is dus elke "00" een NULL byte.

Met -p vind ik er inderdaad allerlei 0 byte characters in, bijvoorbeeld
in deze regel:

2920776974682045534d54500a0969642063643465366430382d64393437
^^

[Paul van der Vlis]

Op 22-05-2022 om 11:11 schreef Miquel van Smoorenburg:

> In article <t6bnut$r7r$1...@dont-email.me>,
> Paul van der Vlis <pa...@vandervlis.nl> wrote:
>> Op 21-05-2022 om 23:39 schreef Coen:
>> Postfix (=SMTP) neemt ze netjes aan, maar de IMAP server (Cyrus IMAP)
>> weigert ze:
>> ----
>> May 21 14:10:34 sigmund postfix/lmtp[29862]: E5D0C2041C:
>> to=<x...@mail.vandervlis.nl>,
>> relay=mail.vandervlis.nl[/var/run/cyrus/socket/lmtp], delay=0.19,
>> delays=0.14/0.02/0.03/0.01, dsn=5.6.0, status=bounced (host
>> mail.vandervlis.nl[/var/run/cyrus/socket/lmtp] said: 554 5.6.0 Message
>> contains NUL characters (in reply to end of DATA command))
>
> Als Cyrus IMAP geen NUL characters wil accepteren maar via LMTP wel
> zegt dat er 8BITMIME support is, dan is dat een bug in Cyrus.

Het bericht ziet er ongeveer zo uit:
-------
<headers, waarin ook "MIME-Version: 1.0">

--MM3-12345-789
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Je hebt een nieuwe voicemail ontvangen van 06xxxxxxx op 21/05/2022 om
22:51:35 uur. Het bericht duurt 9 seconden.<C0><80>

--MM3-12345-789
Content-Type: audio/mpeg
Content-Disposition:attachment; filename= "voicemail.mp3"
Content-Transfer-Encoding:base64

//uQRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA (....)
--MM3-12345-789--

----------

Ben ik correct als ik zeg dat het bericht beweerd 7bit te zijn?
Of geldt dat alleen voor het tekstdeel?

Als het niet geldt voor het audio-deel, dan lijkt me dat daar geen
charset is gedefinieerd.

> Als je googlet op deze melding zal je zien dat je lang de enige
> niet bent met dit probleem.

Je zult merken dat een aantal van die berichten van mij zijn. Ik kom het
probleem weleens tegen bij het overzetten van oude e-mail bestanden via
IMAP. Vaak mail afkomstig van iets als Outlook Express.

In de praktijk zie ik geen e-mail binnenkomen met NUL characters op mijn
mailserver, en Cyrus IMAP gebruik ik al een kleine 20 jaar denk ik.

Cyrus ondersteund RFC1652, en dat is volgens mij 8BITMIME support.
https://datatracker.ietf.org/doc/html/rfc1652.html

> De oplossing is 8BITMIME support uitzetten in Cyrus IMAP zodat Postfix
> dat ook niet probeert. Ik weet niet of Postfix actief aan
> MIME 8bit -> 7bit recoding doet (zou wel moeten!) - indien niet,
> dan moet je maar 8BITMIME support in Postfix uitzetten.

Mijn indruk is dat Cyrus prima 8bit support heeft. Alleen geen NUL
characters, omdat dat niet mag volgens de RFC RFC3501.

Groet,
Paul

[Alex Plantema]

Op zo 22-05-2022 om 15:56 schreef Paul van der Vlis:

> Met -p vind ik er inderdaad allerlei 0 byte characters in, bijvoorbeeld in deze regel:
>
> 2920776974682045534d54500a0969642063643465366430382d64393437
>                        ^^

Dat lijken me bytes 50 en 0a, dus geen nulcharacter.

--
Alex.

[Flibsy]

Ik had eerder geen zin dat te checken, zo'n vergissing zal Paul toch niet
maken? Wél dus.

--
Flibsy

[Rob]

Paul van der Vlis <pa...@vandervlis.nl> wrote:
> Op 22-05-2022 om 10:54 schreef Rob:
>> Paul van der Vlis <pa...@vandervlis.nl> wrote:
>>> Hallo,
>>>
>>> Voicemailberichten van de KPN komen niet aan op mijn mailserver met
>>> Cyrus IMAP omdat ze NUL characters bevatten. Tenminste dat zegt mijn
>>> mailserver.
>>
>> Hoe ziet zo'n bericht er dan uit? Is het "voice" deel van het bericht
>> niet mime-encoded dan? (zoals normaal gesproken ieder attachment)
>
> Zoiets:
>
> <headers>
>
> --MM3-12345-789
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> Je hebt een nieuwe voicemail ontvangen van 06xxxxxxx op 21/05/2022 om
> 22:51:35 uur. Het bericht duurt 9 seconden.<C0><80>
>
> --MM3-12345-789
> Content-Type: audio/mpeg
> Content-Disposition:attachment; filename= "voicemail.mp3"
> Content-Transfer-Encoding:base64
>
> //uQRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA (....)
> --MM3-12345-789--
>
> Groet,
> Paul

Dat soort berichten zouden geen NUL bijtes in moeten zitten.
Maar ik zie daar achter dat 9 seconden al wat "crap" staan dus
wellicht zit er door een bug in de software ook ergens een NUL
byte in en gaat het daardoor fout.

[Paul van der Vlis]

Op 22-05-2022 om 15:56 schreef Paul van der Vlis:

> Op 22-05-2022 om 10:51 schreef Rob van der Putten:
>> Hoi
>>
>>
>> On 22/05/2022 10:38, Paul van der Vlis wrote:
>>
>>> Op 22-05-2022 om 09:46 schreef Rob van der Putten:
>>>> On 22/05/2022 00:09, Paul van der Vlis wrote:
>>>
>>>>> Ik heb hier ondertussen een bericht. Maar hoe zoek ik daarin nu
>>>>> naar zo'n NUL character om het zeker te weten?
>>>>
>>>> Als je het ergens in een filetje hebt, xxd en dan grep lijkt me.
>>>
>>> Hoe wordt zo'n NUL character dan weergegeven in xxd?
>>
>> Standaard " 00" of "00 ".
>> Met '-p' is het wat kaler en is dus elke "00" een NULL byte.
>
> Met -p vind ik er inderdaad allerlei 0 byte characters in, bijvoorbeeld
> in deze regel:
>
> 2920776974682045534d54500a0969642063643465366430382d64393437
>                       ^^

1212121212121212121212121212

Je hebt gelijk. Maar ik heb meer regels.

Best lastig te controleren, groepperen zou fijn zijn. Maar dat gaat weer
niet samen met dat "-p" commando zo lijkt het...

[Paul van der Vlis]

Op 22-05-2022 om 20:37 schreef Flibsy:

Inderdaad... ben niet perfect.

[Miquel van Smoorenburg]

In article <t6dfmh$q7h$1...@dont-email.me>,

Het tekstdeel beweert 7bit te zijn. Daar zit zo te zien wel iets
raars in: wat is die "<C0><80>"? Vreemd.

Het audio/mpeg deel is als base64 ge-encode, en dat lijkt ook echt base64
te zijn. Dat daar dan een als base64 ge-encode NUL zit is niet gek; een
mp3 bevat alle waardes van 0-255.

>Als het niet geldt voor het audio-deel, dan lijkt me dat daar geen
>charset is gedefinieerd.

Het is binary. Content-Type: audio/mpeg heeft geen charset. Alleen
Content-Type: text/nog-iets-hier heeft een charset.

>Cyrus ondersteund RFC1652, en dat is volgens mij 8BITMIME support.
>https://datatracker.ietf.org/doc/html/rfc1652.html
>
>> De oplossing is 8BITMIME support uitzetten in Cyrus IMAP zodat Postfix
>> dat ook niet probeert. Ik weet niet of Postfix actief aan
>> MIME 8bit -> 7bit recoding doet (zou wel moeten!) - indien niet,
>> dan moet je maar 8BITMIME support in Postfix uitzetten.
>
>Mijn indruk is dat Cyrus prima 8bit support heeft. Alleen geen NUL
>characters, omdat dat niet mag volgens de RFC RFC3501.

Het lijkt me toch sterk dat dit het probleem is. Als Cyrus 8BITMIME
beweert te doen over LTMP, dan moet die gewoon ook dat accepteren
en niet "ja hoor eens ik accepteer bijna alle waardes van 0 t/m 255
oh wacht nee, 0 niet". In elke binary attachment zit wel een 0.
Dus dat zal toch wel intern omgezet worden in een
Content-Transfer-Encoding: base64 voordat het in een mailbox wordt gezet.

Misschien zit er ergens anders iets mis. In een header misschien.
En ik vind die <C0><80> in de text body ook maar raar.

Mike.

[Alex Plantema]

Op ma 23-05-2022 om 00:25 schreef Miquel van Smoorenburg:

> Misschien zit er ergens anders iets mis. In een header misschien.
> En ik vind die <C0><80> in de text body ook maar raar.

Dat ziet er uit als overlong gecodeerd nulcharacter:
https://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8

--
Alex.

[Rob]

Ja dan is het gewoon een bug in het programma bij KPN wat die mails
opstelt denk ik, wat per ongeluk die NUL aan het eind van een stukje
tekst ook meestuurt (lengte van een write verkeerd opgegeven?) en
daardoor alles in de war brengt.

Veel software zal die NUL wellicht gewoon weggooien (en evt de newline
die erachter staat) en dan merk je helemaal geen probleem.

Dat gaat vast een leuke worden om te melden.
"nee hoor meneer er is geen probleem het werkt hier gewoon goed".

[Rob]

Paul van der Vlis <pa...@vandervlis.nl> wrote:

-g1 zoals ik al schreef. dan komen alle bytes in het hex deel apart
te staan en herken je de NUL direct als " 00 ".

[Paul van der Vlis]

Op 23-05-2022 om 10:11 schreef Rob:

Ik vind op die manier geen NUL character.

Misschien omdat het overlong gecodeerd is?

[Paul van der Vlis]

Op 21-05-2022 om 22:18 schreef Paul van der Vlis:

> Hallo,
>
> Voicemailberichten van de KPN komen niet aan op mijn mailserver met
> Cyrus IMAP omdat ze NUL characters bevatten. Tenminste dat zegt mijn
> mailserver.
>
> RFC3501 is er best wel duidelijk in dat dat niet mag en mijn mailserver
> heeft geen optie om ze toch maar te accepteren, voor zover ik weet.
>
> Hmm.

Ik gebruik Postfix voor SMTP, dat blijkt een optie te hebben om 0
characters te verwijderen uit e-mail:
https://www.postfix.org/postconf.5.html#message_strip_characters

Hiermee komen de voicemail berichten aan!

Of het ook nog nadelen heeft weet ik nog niet...

Groet,
Paul

[Rob]

Paul van der Vlis <pa...@vandervlis.nl> wrote:

> Op 21-05-2022 om 22:18 schreef Paul van der Vlis:
>> Hallo,
>>
>> Voicemailberichten van de KPN komen niet aan op mijn mailserver met
>> Cyrus IMAP omdat ze NUL characters bevatten. Tenminste dat zegt mijn
>> mailserver.
>>
>> RFC3501 is er best wel duidelijk in dat dat niet mag en mijn mailserver
>> heeft geen optie om ze toch maar te accepteren, voor zover ik weet.
>>
>> Hmm.
>
> Ik gebruik Postfix voor SMTP, dat blijkt een optie te hebben om 0
> characters te verwijderen uit e-mail:
> https://www.postfix.org/postconf.5.html#message_strip_characters
>
> Hiermee komen de voicemail berichten aan!
>
> Of het ook nog nadelen heeft weet ik nog niet...

Denk het niet, omdat uiteindelijk gebleken is dat het allemaal kwam
door een bug in de KPN voicemail applicatie.
Kijk, als het daadwerkelijk de voice data was die die nullen bevatte,
omdat die op een of andere manier unencoded in de mail terecht kwam,
dan was het natuurlijk een ander verhaal geweest.
Maar nu gaat het alleen maar om een overbodige header. Het kan je
hooguit "DKIM mismatch" opleveren, maar ik schat in dat KPN die mail
niet eens DKIM signed. Dat zou met deze kwaliteit van programmeren
toch ook een drama worden.