[Mailman-Users] Perplexing HTML formatting issue

[Mark Sapiro]

Brian Carpenter wrote:
>
>I have a client who is using us to host his mailman list but he has his main
>web site hosted with another provider. He uses a php script to post html
>formatted messages to the list from this web site. Last week he moved his
>web site to a new hosting provider and now when his script sends messages to
>the list, the html formatting is not coming through. He tested the script to
>post to one of his e-mail addresses and the formatting came through fine but
>when he posts to the list via this php script, the html formatting is lost.
>He says he did not change any of his list settings and I looked at them and
>they look fine. He has content filtering set to no. Here is what the post
>looks like when you view it in an e-mail client:
>
>> From: Client <admin@****.com>
>> Date: February 9, 2009 2:36:39 PM EST
>> To: ****-news at list.****.com
>> Subject: [****-News] Weekly Newsletter (Feb 09, 2009)
>> Reply-To: no-reply@****.com
>>
>> Content-Type: text/html; charset = "utf-8"
>>
>> Content-Transfer-Encoding: 8bit


He's using the php mail() function to create the mail, and he's adding
the Reply-To:, Content-Type: and Content-Transfer-Encoding: headers as
additional_headers, and he believes the documentation which says that
each header should be terminated with "\r\n". This is causing blank
lines to be inserted because both "\r" and "\n" are taken as line
terminators. Thus, in the above, Reply-To: is taken as the last header
and Content-Type: and Content-Transfer-Encoding: become part of the
message.

See the note under additional_headers at
<http://us3.php.net/manual/en/function.mail.php> which says:

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.

Aside from the fact that what this note says is totally bogus, at least
in so far as RFC 2822 compliance is concerned, it gives the solution.
Note that it is the php implemantation that is poor quality, not the
MTA. The MTA is doing it's job in converting local OS line endings
into CRLF for transmission over the wire as the RFCs say it should.

I'm convinced this is the problem, and the fix is to use only "\n" as a
line terminator for additional_headers, but if for some reason this
isn't it, please provide a raw message as sent by php.

Note also, that the pear Mail_Mime package is a much more robust way of
creating MIME messages.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan