Hi,
Version : 9.2.2 / Debian 4.0
I recently received a lot a failure messages in my postmaster mailbox :
While scanning the tcp communication, I finally noticed there was a NUL char (0x00h) in the e-mails generating this error.
I tried to add the "message_strip_characters = \0" statement in the postfix main.cf but it looks useless as postfix seems to directly pass the data to the plesk postfix-queue (before-queue).
I then replaced the :
by :
remove00.pl simply scans the data, remove the NUL char(s) and sends the result via SMTP to the 10025 port. Then, the plesk postfix-queue (before-queue) acts normally and the message can be delivered.
Therefore, I think this is the plesk postfix-queue (before-queue) that cannot support the NUL char.
This is easy to reproduce this issue by sending a mail containing a NUL char.
Thanks
Best regards
Version : 9.2.2 / Debian 4.0
I recently received a lot a failure messages in my postmaster mailbox :
Transcript of session follows.
Out: 220 mx.********.fr : ********.fr MX
In: EHLO **********
Out: 250-mx.********.fr
Out: 250-PIPELINING
Out: 250-SIZE 20971520
Out: 250-VRFY
Out: 250-ETRN
Out: 250-XFORWARD NAME ADDR PROTO HELO SOURCE
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250 DSN
In: MAIL FROM:<nicolas@********.com>
Out: 250 2.1.0 Ok
In: RCPT TO:<admin@********.fr>
Out: 250 2.1.5 Ok
In: DATA
Out: 354 End data with <CR><LF>.<CR><LF>
Out: 451 4.3.0 Error: queue file write error
Session aborted, reason: lost connection
While scanning the tcp communication, I finally noticed there was a NUL char (0x00h) in the e-mails generating this error.
I tried to add the "message_strip_characters = \0" statement in the postfix main.cf but it looks useless as postfix seems to directly pass the data to the plesk postfix-queue (before-queue).
I then replaced the :
smtp inet n - - - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025
by :
smtp inet n - - - - smtpd -o content_filter=remove00:
remove00 unix - n n - - pipe
flags=DORhu user=mhandlers-user argv=/etc/postfix/remove00.pl ${recipient} ${sender}
remove00.pl simply scans the data, remove the NUL char(s) and sends the result via SMTP to the 10025 port. Then, the plesk postfix-queue (before-queue) acts normally and the message can be delivered.
Therefore, I think this is the plesk postfix-queue (before-queue) that cannot support the NUL char.
This is easy to reproduce this issue by sending a mail containing a NUL char.
Thanks
Best regards