Am 12.12.2012 10:19, schrieb Jeroen van Meeuwen (Kolab Systems):
On 2012-12-11 19:25, Michael Heydekamp wrote:
Since the move from SVN to GitHub, the format of the messages in the SVN list looks a bit strange to me:
- Roundcube is displaying the attachment icon for each message, although
there is no attachment at all in any of the messages.
Actually GitHub sends the original message as a mime part, and mailman therefore "attaches" the mailing list footer (Content-Disposition: inline, though).
Sure, but wasn't that the same procedure before the move to GitHub, when those messages were still coming from trac@roundcube.net?
But anyway: Roundcube apparently and already detects that there is no attachment, as it doesn't offer to download any attachments (below the header section). So why does it display the attachment (paper clip) icon in the attachment column then...?
- All messages are declared as "multitype/mixed" for no real reason (the
second part just containing the signature, this could perfectly be appended to the first part without creating a second part).
Here too, the Content-Type is slightly different - the original GitHub message and the mailman mailing list footer claim to use a different charset.
Yes, I can see that, but I just don't see the reason why. The list footer is declared as US-ASCII, the first part of the message (apparently blindly) as UTF-8. As US-ASCII is a subset of UTF-8, there is no reason to create a second part - even if the entire message (including the footer) would be declared as UTF-8, it would be perfectly correct.
- The Content-Type of the first part (i.e. the real content of the
message) is "text/plain; charset=UTF-8", the Content-Transfer-Encoding "7bit". If CTE is 7bit, shouldn't the charset be "US-ASCII" then? The UTF-8 declaration will probably (and unnecessarily) invoke a decoding routine in most MUAs, although there is nothing to decode.
I suppose there's only nothing to decode (most of the time) because there's no actual utf-8 characters included in the message - but a commit message may contain utf-8 characters, of course.
Right, it MAY. But if it doesn't, then there is no need to declare UTF-8, IMO.
Anyway, that leads me to a different question in terms of composing messages with Roundcube in general: Is there any chance to check the content of a message upon sending and to declare the "least invasive" charset, rather than blindly declaring UTF-8 no matter what?
I'm using the plugin "sendcharset" to avoid blindly declaring UTF-8 always, but this approach is as blind as well (because if I should use characters outside ISO-8859-1, they will not been transfered and displayed correctly - but just as "?").
I can see that you are declaring "us-ascii" with your message (how did you do that?) and are using "Roundcube Webmail/0.9-0.15.git0fa54df6.el6.kolab_3.0". Did you already implement a routine that is checking the body of a message and then declaring the least invasive charset?
If so, I'd like to have it. ;) If not, what would happen if you would use just one 8bit character in your message - still declaring "us-ascii"...?
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany