comment notification encoding error

[Maex]

s9y 1.5.2
but error is present since the very first version I guess.

email notifications (to the admin) are sent to me as
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
however "quoted-printable" implies that lines *MUST* be broken up at character position 76, which does not happen.

RFC2045 states:
(Soft Line Breaks) The Quoted-Printable encoding REQUIRES that
encoded lines be no more than 76 characters long. If longer
lines are to be encoded with the Quoted-Printable encoding,
"soft" line breaks must be used. An equal sign as the last
character on a encoded line indicates such a non-significant
("soft") line break in the encoded text.

The result is that my mail client (mutt) does not display the contents of the messages correctly.
Also some spam filters (like spamassassin) will put a penalty on messages like that, as spammers also make this mistake a lot which may result in the messages ending up in the spam folder.

Replacing
$maildata['message'] = str_replace("=\r\n", "", imap_8bit($maildata['message']));
with
$maildata['message'] = chunk_split(imap_8bit($maildata['message']),75,"=\r\n");
did the trick for me.
File: include/functions.inc.php:function serendipity_sendMail() line 530

Also it would be nice, if the messages would have a Auto-submitted header:
http://www.iana.org/assignments/auto-su ... ords.xhtml
I guess
Auto-submitted: auto-generated
would be appropriate.

\Maex

[garvinhicking]

Hi!

Hm, I believe there was a reason for this in this commit:

http://svn.berlios.de/viewcvs/serendipi ... 934&r2=963

I would need to research the php-blog mailinglist and this forum for postings around that date to see why it was necessary. I believe one reason was that otherwise long links might get wrapped around, and many mailclients would then not display the links correctly.

So while the RFC states one thing, it might in fact kill Outlook or other systems, so it's a tough decission where somebody's gotta loose. I'd say though that mutt is used by fewer people than outlook, so we might stick to the variant that introduces the least b0rkage for the largest sum of people.

s9y alternatively uses base64 encoding when imap_8bit is not available. But I dislike about base64 that such mails are not grep'able, and much rather like sending mails in human readable format.

The Auto-Submitted header is a good idea, I added that.

Regards,
Garvin

[Maex]

Hi Garvin,

while I usually tend to not break correct working apps to work around bugs in b0rken apps I understand your point.
Also, as I guess, it will also affect mail notifications to comment subscribers and thus a wider range of users than just the admins.

I have created a comment to a blog post with a long title, so the links in the message have to be broken up.
To send it I used the (corrected) line
$maildata['message'] = imap_8bit($maildata['message']);
Lines are broken up within the URLs like in
... http://blog.maexotic.=
de/delete/comment/ ...

Checked the message with
* mutt 1.4.2.3i
* Mozilla Thunderbird 3.0.1
* Outlook Express 6 (6.00.2900.5512; Windows XP Home Edition)
(that's all i currently have access to) and all display correctly and links are clickable and result in correct URLs.

Oh, and Facebook had the same problem. After I complained they fixed it They also have URLs in the messages that are longer than 76 chars, so I guess if it works for them ... (not trying to pressure s.o., just FYI).

Cheers,
\Maex

[garvinhicking]

Hi!

Okay, if Facebook can, so can we

I just committed it - reading the PHP's and your comment, it seems that chunk_split is not required, imap_8bit does this on its own? I just committed it this way to SVN trunk.

Regards,
Garvin