This causes issues for me mainly because I do a reasonable amount of my mail reading using my phone. It’s no fun wading through pages of diff on an undersized screen such as a mobile phone when the “content” you’re looking for is a one line comment somewhere in the middle. Even on a full size screen it’s often difficult to locate a small piece of new text, but there it needs a much bigger haystack to be an issue.

Please, if you’re one of the people who do this have pity on those of us Reading your messages on smaller devices!

The obvious one is Outlook, which has well known idiosyncracies but which some companies force their employees to use even for free software work. The  other is GMail. GMail has two problems. One is that the UI appears to encourage people to insert their text into the middle of messages without deleting any context. This makes it hard to notice the new content in big e-mail threads or when someone’s commenting on large patches – searching for the new text is like looking for a needle in a haystack. That said, this is at least partly a user issue – many people manage to use GMail without doing this, it’s just that the GMail UI seems to encourage it more than most other UIs.

The other thing is is that it’s recently decided to format the author information for quoted text in a very odd way:

On Sun, Jun 14, 2009 at 11:00 PM, Mark
Brown<broonie@opensource.wolfsonmicro.com> wrote:

What’s happened is that it’s decided to remove the space between the author name and the e-mail address. This causes a very odd word wrapping on the very first line of the message and is really noticable when you’re reading. I’m not sure what inspired that change, there doesn’t seem to be any motivation for it, but it doesn’t seem terribly helpful.

This can be triggered relatively easily on a Debian system by telling Exim to use all the certificates provided by the ca-certificates package (which is the default configuration). The Windows clients will give an unhelpful “the remote end dropped the connection” style error, caused by the server getting upset by the unexpected fallback to unencrypted SMTP. The server logs will show something like this:

2009-02-17 21:32:55 TLS error on connection from client.example.com (Client) [192.168.192.168] (gnutls_handshake): A TLS packet with unexpected length was received.
2009-02-17 21:33:00 SMTP protocol synchronization error (input sent without waiting for greeting): rejected connection from H=client.example.com [192.168.192.168] input="EHLO Client\r\n"

Configuring the MAIN_VERIFY_TLS_CERTIFICATES option in the Debian Exim configuration (which sets the tls_verifiy_certificates option in the actual Exim configuration) to point to something with less certificates in should avoid the issue.

On the bright side, at least they’re making an effort to avoid overflows.

In practice there are relatively few configuration options that users are expected to configure so it may be easier to redo the configuration based on the example provided. For safety it’s best to delete your existing CSS files too in case they’ve been invalidated by a configuration or format change.

It’s all a bit manual but it’s worth it for what it does for my inbox.

What Apple Mail does here is to only enable the more complex formatting options if they add information that can’t be represented in the less complex formats. By default mails are sent in text/plain with the format=flowed option to let the reader know it can safely reflow the text and no HTML alternative is generated. If something that can’t be represented using format=flowed is included in the message then a HTML alternative is generated – transparently and without user intervention.

This is good partly because it’s nice to see format=flowed used, it’s a nice technical solution to the problem, but mostly because it’s great user interface design. Most Apple Mail users will never notice if it is or isn’t generating HTML e-mail, they’ll just see that it’s doing what they expect and won’t have to deal with an option that they probably don’t understand or have much of a view on. Other users won’t be troubled with HTML generated by Apple Mail users unless there is some content in the formatting. It’d be good to see more MUAs implementing similar behavior, at least optionally.

Not that this should be in any way news or non-obvious.

As one would expect the client verifies the signatures on the certificate offered by the IMAP server and will prompt the user if it sees signatures that it can’t trace back to an authority it trusts. Unfortunately it is not possible to tell the device to remember the decision which means that when the device prompts it will prompt every time it connects to the server in question. The result of this is user irritation and a reduction in security since there is much less chance that a changed server certificate will be noticed.

You would expect that there would be a lot of users encountering this given that so many sites don’t use a signed certificate but it turns out that this is not the case. Someone must have realised how many systems would be affected and so a solution was provided – if the server is using an unsigned certificate then the phone will accept it without warning the user at all. Only servers with signatures from an unknown trust source like a private certificate authority will cause the user to be prompted to verify the server certificate. This avoids both user irritation and any chance that the user will actually verify the fingerprint of the server they are connecting to, exposing users to spoofing and redirection based attacks.

Clearly someone hasn’t thought through what they’re doing here – it all rather defeats the point of signing in the first place. On the bright side, this is the first Symbian phone I have seen where the native IMAP client encrypted connections at all so having this problem is progress.

Your membership in the mailing list whatever has been disabled due to excessive bounces The last bounce received from you was dated 15-Sep-2007.

It’s true – the systems that handle my mail do generate a number of SMTP time rejects for open posting SourceForge lists. My mail server does SMTP time rejection of some spam and these lists don’t appear to have much in the way of spam filtering. It’s a bit depressing since the main problem appears to be limited filtering on the SourceForge side which renders the lists in question rather difficult to read but it’s unsurprising given the nature of the service.

Given the general quality of implementation one finds the reasoning behind providing the alternative is probably that there’s some widely deployed piece of software out there which explodes horribly if it sees HMTL outside of a multipart/alternative wrapper. There are probably some users who are sufficiently keen on seeing the HTML version of the message to mean that they would actively wish to avoid using a plain version of it but there can’t be many – I expect the actual reasoning behind not putting it in is ease of implementation.


2006-08-14 21:40:25 1GCk6m-0006ZH-Vu == |/usr/lib/ecartis/ecartis -s xen-tools-commits R=vdom_aliases T=address_pipe defer (0): Child process of address_pipe transport returned 75 (could mean temporary error)
from command: /usr/lib/ecartis/ecartis


with nothing in the Ecartis log by default. Along with a general failure to talk SMTP like Steve found you should also watch out for address checks tripping up on some of the addresses in the list – recipient verification callouts were what bit me. Ecartis will be a lot happier if it can just pump mail into an unquestioning server and have any problems reported via injection of bounce messages.