Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BAD HEADER from local Amavis #2618

Closed
rcubetrac opened this issue Jan 11, 2010 · 13 comments

Comments

@rcubetrac
Copy link

commented Jan 11, 2010

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.

User-Agent: RoundCube Webmail/0.3-stable
X-Virus-Scanned: amavisd-new at xxxxxxxxxxxxxxx.xx
X-Amavis-Alert: BAD HEADER SECTION, Improper use of control character (char 0D
    hex): X-PHP-Originating-Script: 0:func.inc\r
X-PHP-Originating-Script: 0:func.inc

Software used:
Fedora 12[ amavisd-new: 2.6.4[BR]
Postfix: 2.6.5[[BR]]
PHP: 5.3.1

Migrated-From: http://trac.roundcube.net/ticket/1486418

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Jan 11, 2010

Comment by @alecpl on 11 Jan 2010 10:51 UTC

Try to disable mail.add_x_header option in php.ini.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Jan 11, 2010

Milestone changed by @alecpl on 11 Jan 2010 10:51 UTC

later => 0.4-beta

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Jan 11, 2010

Comment by @alecpl on 11 Jan 2010 11:11 UTC

Also you can try to test with Roundcube's mail_header_delimiter="\n";

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Jan 11, 2010

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!

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Jan 11, 2010

Comment by @alecpl on 11 Jan 2010 12:45 UTC

Did you used '\n' or "\n" for delimiter? This is not the same in PHP.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Jan 11, 2010

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)
with "\r\n" I get: INFO: removed bare CR from 8 header line(s)
with "\r" I get: I get: INFO: removed bare CR from 2 header line(s)

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Jan 11, 2010

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:

$header_str = trim($header_str);

before this line:

if (ini_get('safe_mode'))
  $sent = mail($headers_enc[$headers_enc['Subject']('To'],), $msg_body, $header_str);
@rcubetrac

This comment has been minimized.

Copy link
Author

commented Jan 11, 2010

Comment by erikpkn on 11 Jan 2010 21:57 UTC

No, that did not work. Same BAD HEADER message as before.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Jan 22, 2010

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.

INVALID HEADER

  Improper use of control character (char 0D hex): Subject:
    ...2=5F=30=31=33=5Farticle?=\r\n =?UTF-8?Q?=39[...]

It appears RoundCube encoded the mail in UTF-8. The source of the (un)sent message shows the subject as:

Subject: Re: =?UTF-8?Q?NRC=5F=32=30=31=30=30=31=32=31=5F=32=5F=30=31=33=5Farticle?=
 =?UTF-8?Q?=39=2Epdf?=

whereas 'cat -A' reveals it to be:

Subject: Re: =?UTF-8?Q?NRC=5F=32=30=31=30=30=31=32=31=5F=32=5F=30=31=33=5Farticle?=^M$
 =?UTF-8?Q?=39=2Epdf?=$

All other lines in the header are "human readable" ASCII.

The subject of the message I replied to was:

Subject: NRC_20100121_2_013_article9.pdf
@rcubetrac

This comment has been minimized.

Copy link
Author

commented Jan 25, 2010

Comment by @alecpl on 25 Jan 2010 08:41 UTC

@Gui1ty: what happens when you change in steps/mail/sendmail.inc line:

$headers[= mb_encode_mimeheader($headers['Subject']('Subject']), $message_charset, 'Q');

to:

$headers[= mb_encode_mimeheader($headers['Subject']('Subject']), $message_charset, 'Q', $RCMAIL->config->header_delimiter(), 8);
@rcubetrac

This comment has been minimized.

Copy link
Author

commented Jan 25, 2010

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:

Subject: Re: =?UTF-8?Q?NRC=5F=32=30=31=30=30=31=32=31=5F=32=5F=30=31=33=5F?=  =?UTF-8?Q?article=39=2Epdf?=

Thanks!

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Feb 8, 2010

Comment by @alecpl on 8 Feb 2010 11:58 UTC

http://bugs.php.net/bug.php?id=50907. So, assume PHP bug and close this ticket.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Feb 8, 2010

Status changed by @alecpl on 8 Feb 2010 11:58 UTC

new => closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.