Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
BAD HEADER from local Amavis #2618
Reported by erikpkn on 11 Jan 2010 10:38 UTC as Trac ticket #1486418
When sending an e-mail, the local Amavis (at the sending side) reports a BAD HEADER. This happens with every e-mail. The e-mail is forwarded, but I presume an Amavis-installation at the receiving side will not accept it.
Comment by erikpkn on 11 Jan 2010 12:40 UTC
First suggestion (disable mail.add_x_header option in php.ini) worked. No more BAD HEADERs. Am I right to presume that this is a PHP bug?
Second suggestion ($rcmail_config['mail_header_delimiter'] = '\n';) didn't work. Also tried '\r\n' and '\r', but all these caused numerous other problems in the header and didn't solve the BAD HEADERs error.
Thank you for the suggestions!
Comment by erikpkn on 11 Jan 2010 13:07 UTC
You're right. Forgot about that. But "\n" didn't work either. Neither did "\r\n" and "\r". But in my maillog the different settings cause different messages:
with NULL or "\n" I get: INFO: removed bare CR from 1 header line(s)
Comment by @alecpl on 11 Jan 2010 13:44 UTC
I'm trying to find a workaround. What if you add in steps/mail/funct.inc in function rcmail_deliver_message() a line:
before this line:
Comment by gui1ty on 22 Jan 2010 21:50 UTC
I worked around the BAD HEADER X-PHP-Originating-Script line, just to have the same message blocked on the Subject line.
It appears RoundCube encoded the mail in UTF-8. The source of the (un)sent message shows the subject as:
whereas 'cat -A' reveals it to be:
All other lines in the header are "human readable" ASCII.
The subject of the message I replied to was:
Comment by @alecpl on 25 Jan 2010 08:41 UTC
@Gui1ty: what happens when you change in steps/mail/sendmail.inc line:
Comment by gui1ty on 25 Jan 2010 09:11 UTC
Replying to alec:
I changed the line and the messages is no longer blocked by Amavis.
The subject line now looks like: