Thomas -Balu- Walter wrote:

Hello everyone,

I just subscribed today, and the only note regarding this issue I found so far was by David Fontaine on Fri Oct 21 2005.

RoundCube fails to send mail if the safe_mode is active and the PHP mail() is used, because the 5th parameter is disabled in that case.

I'd suggest to change the mail()-line in program/steps/mail/sendmail.inc to something like the following:

if ((bool)ini_get('safe_mode')) { $headers_php['Errors-To'] = $from; $header_str = $MAIL_MIME->txtHeaders($headers_php); $sent = mail($mailto, $msg_subject, $msg_body, $header_str); } else { $sent = mail($mailto, $msg_subject, $msg_body, $header_str, "-f$from"); }

Regarding to my sendmail man page -f is used to "Set the envelope sender address. This is the address where delivery problems are sent to, unless the message contains an Errors-To: message header."

Since the envelope sender can not be set because of the safe_mode restriction, my version adds the "Errors-To:" header as the man page suggests.

Please note the following from the Postfix Changelog.

Cleanup: support for the non-standard Errors-To: header is removed. File: cleanup/cleanup_message.c.

Also, RFC 822 doesn't mention Errors-To anywhere and it's discouraged in RFC 2076 (http://www.faqs.org/rfcs/rfc2076.html).

So please leave out the Errors-To header and there is no guarantee it is supported on other mailservers besides sendmail.

The Return-Path: in this case will usually be something like "www-data@www.example.com", but it shouldn't hurt that much anymore, since bounces should be returned to the Errors-To: address.

No, they should not according to the RFC.

 Balu

Or write the parameters in a file temporarily and read them in to send mail.

-- Robi

On 11/14/05, Thomas -Balu- Walter list+roundcube-dev@b-a-l-u.de wrote:

On Mon, Nov 14, 2005 at 11:51:11PM +0100, Jasper Slits wrote:

...

...

Regarding to my sendmail man page -f is used to "Set the envelope sender address. This is the address where delivery problems are sent to, unless the message contains an Errors-To: message header."

Since the envelope sender can not be set because of the safe_mode restriction, my version adds the "Errors-To:" header as the man page suggests.

Please note the following from the Postfix Changelog.

Cleanup: support for the non-standard Errors-To: header is removed. File: cleanup/cleanup_message.c.

*grr* once you believe what the postfix sendmail man page says and then it's non-standard :-/. Forget what I wrote...

We should still try to find a way around the 5th parameter though.

Or tell people that a requirement for mail() is safe_mode = Off. People might get around this problem by using the mailserver way of sending mails in this case.

 Balu

Hello all,

my local amavisd-new reports a problem with the header of mails sent by roundcube:

X-Amavis-Alert: BAD HEADER Improper use of control character (char 0D hex) in message header 'MIME-Version' MIME-Version: 1.0\r\n ^

It's late and I'm tired, so I didn't check yet, what might cause this...

 Balu

Hallo Dave,

This is again related to the same header problem that's being experienced by some in gmail, and qmail-scanner.

All mail headers should only be terminated by a \n, not a \r\n.

Header fields are lines composed of a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF.

[ http://www.faqs.org/rfcs/rfc2822 ]

Note: If messages are not received, try using a LF (\n) only. Some poor quality Unix mail transfer agents replace LF by CRLF automatically (which leads to doubling CR if CRLF is used). This should be a last resort, as it does not comply with RFC 2822.

[ http://www.php.net/manual/en/function.mail.php ]

qmail is very strict, a patch exists to accept \n:

"qmail by default violates the 'be liberal in what you accept' rule when receiving mail via smtp. It enforces strict \r\n behaviour... which is exactly what the standard dictates."

[ http://www.arctic.org/~dean/patches/qmail-0.95-liberal-lf.patch ]

Doesn't seem to be a roundcube specific problem - the used MTA is to blame...

Best regards, Lars