Dear all,
When using the mail() function in php from a web page on the OSX
10.5 server (see example code below), only the first header is
processed but the other headers are added to the body of the email
and are not processed as header for the email.
The same exact code works just fine on the OS X10.4.11 server.
It seems to be a postfix related issue on how to handle the return
characters because it works fine if I replace the \r\n by \n but
then may not work right on 10.4.
Hello Bruno,
Have you tried it? I mean, to use \n on 10.4?
I just tried here on a 10.4.11 stock install, and it seems to be
fully functional.
Moreover, IIRC, I never worried to user \r\n when building the
$additional_headers argument of the mail() function.
\r\n (CRLF) is the standard header delimiter per RFC 2822:
2.2. Header Fields
Header fields are lines composed of a field name, followed by a
colon (":"), followed by a field body, and terminated by CRLF
Yes, but that doesn't mean that /usr/sbin/sendmail itself expects such
line endings!
In fact, the role of /usr/sbin/sendmail when used locally and
interactively is to fetch each line entered by the user in turn, to
pre-process it, then to build an RFC-compliant message which will be
queued and sent by the postfix system.
To take an example:
$ sendmail -t -i email@hidden<ENTER>
To: email@hidden<ENTER>
Subject: test message<ENTER>
From: email@hidden<ENTER>
Reply-To: email@hidden<ENTER>
X-Mailer: postfix/sendmail<ENTER>
<ENTER>
Hello<ENTER>
Axel<ENTER>
<cCTRL-D>
and I get a perfectly valid message in my mailbox (<ENTER> and <CRTL-
D> designate keystrokes).
\n also working is not a bug, but \r\n not working definitely is a
bug.
According to PHP's source code, this would anyway be consistent
with the handling of the other parts of the message to be sent with
the help of /usr/sbin/sendmail.
And this is what PHP's code does when executing mail($to, $subject,
$message, $additional_headers), expressed in pseudo-code and skipping
some details:
open a pipe for process "/usr/sbin/sendmail -t -i"
write "To: $to\n" to the pipe
write "Subject: $subject\n" to the pipe
write "$additional_headers\n" to the pipe
write "\n$message\n" to the pipe
close the pipe
It appears that PHP sends LF-terminated lines to /usr/sbin/sendmail,
not CRLF-terminated ones.
By its design, it is up to /usr/sbin/sendmail to convert its input
into an RFC compliant message.
It's clearly stated in the documentation of mail() that message (the
only other field with line breaks) and additional_headers have
inconsistent line break conventions. There's a note addressing this
exact problem:
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.
So using \n may solve this problem on a specific flawed system, but
that's a clear deviation from the standard and should not be
encouraged nor expected to work more generally.
Yes, I read that one too.
Must be a documentation bug...
Looks like to be a change in the /usr/sbin/sendmail binary of the
postfix system. As if it didn't care anymore to check for \r\n line
endings (btw, such endings don't make much sense in an interactive
session on a unix box).
Sure they do; \r\n is the standard delimiter for email headers, so
it should work in *any* email system, regardless of the local
convention. That's the whole point of specifying it in the RFC
standard.
But sure, we agree upon the fact that the RFC governs the format of
the message to be exchanged through an SMTP session.
Axel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Web-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/web-dev/email@hidden
