Serendipity Forums

garvinhicking wrote:Our plugin routines allow to hook into a plugin that sets mail headers there easily.

Giving config options for this is a hard thing to do, because with the current way everything should work flawlessly. Actually, it would work, if your MTA wouldn't be autoconverting anything. I only know debian linux, and it doesn't do this neither with postfix nor sendmail nor exim.

And as I mentioned, using 8bit is not an option for several email clients out there...

I understand that you want to make s9y work out of the box, but if something on the MTA side is changing what s9y wants to send, we're a bit at loss there...

Regards,
Garvin

You seem to have a broader understanding of this than I do. So, does the php mail() function by default send mail that may not be in a format supported by some client applications?

I can see what you are saying about the MTA changing the mail. You say you only have experience with Debian. Well, here I am with more than a dozen freeBSD servers and willing to help.

The only relevent sendmail config stuff that I could find was:

# strip message body to 7 bits on input?
O SevenBitInput=False

# 8-bit data handling
O EightBitMode=pass8

Both of these are set to the default on the server sending the message and on the server recieving the message. THis is also the setting on my other FreeBSD servers.

This must have affected someone else.

I guess why I'm so hung up on this is that your auto upgrade facility is fantastic but to use it effectively I need to have stock code. I don't want to have to remember what I changed everytime I upgrade the software.

Hands down serendipity is the best blog software we have come across and my company is really looking forward to going live with it.

What I'd like is a way for serendipity to work with the default sendmail configuration on FreeBSD. Would adding IMAP support to my php install help? Would that make the imap_8bit function available?

Thanks

Hi!

Yes, the PHP mail() command does not set any headers. So if you send a UTF-8 email, no mail client will recognize the email with UTF-8 encoding.

Thus, the PHP mail() function needs additional headers to pass on to correctly handle UTF-8. We do that with the base64 encoding or the quoted-printable method. But if the MTA interfers and overrides our text and introduces buggy binary characters, we have little options available to prevent that.

Can it be that you're using some antivir or others? Did you try to google up which MTAs or which applications could inject that X-MIME-Autoconverted? Maybe it's your mail CLIENT even? Or some procmail filter on the receiving end, not the sending side?

What I'd like is a way for serendipity to work with the default sendmail configuration on FreeBSD. Would adding IMAP support to my php install help? Would that make the imap_8bit function available?

Yes, this option would then get available, maybe you could try it out?

I would really like to get my hands dirty on that freebsd issues, but I'm currently all out of time and see at least another 4-5 weeks before I'd have the time to inspect issues like these. :-/(

HTH,
Garvin

I noticed that the base64 conversion is only done when the character set is set to UTF-8. I went into the blog configuration and set the Character set to "Native".

The emails now come through unmolested and uncorrupted.

What problems can arise by setting the character set to Native (which appears to be ISO-8859-1) as opposed to UTF-8?

Thanks!

Hi!

Usually, ISO-8859-1 is no problem at all. Problems can arise if you decide to use multilingual features and want to offer other languages on your blog...

Best regards,
Garvin

I've been having the same problem, and I wouldn't be surprised if other have it too but don't realize it. It seems to only happen with longer emails (over 30 lines or so). I assume it definitely has something to do with the encoding. For a while I ignored it because I figured it was a fluke, or someone entered a bit of garbage in a comment or something but then I began realizing I was losing the whole email past the first 20 lines or so. Commenting out the UTF-8 code in the _sendmail() in functions.inc.php also worked for me to solve it.