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 <ad...@****.com> >> Date: February 9, 2009 2:36:39 PM EST >> To: ****-n...@list.****.com >> Subject: [****-News] Weekly Newsletter (Feb 09, 2009) >> Reply-To: no-re...@****.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 <m...@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
