Subscribe: Technicalities » Planet Debian
http://www.sirena.org.uk/log/?feed=atom&cat=10
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
apple mail  certificate  client  configuration  lot  mail  message  messages  people  plain  server  text plain  text  user  version 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Technicalities » Planet Debian

e-mail – Technicalities



Just another random blog



Updated: 2017-04-23T13:17:45Z

 



Maintaining your email

2016-02-09T19:47:52Z

One of the difficulties of being a kernel maintainer for a busy subsystem is that you will often end up getting a lot of mail that requires reading and handling which in turn requires sending a lot of mail out in reply. Some of that requires thought and careful consideration but a lot of it […]One of the difficulties of being a kernel maintainer for a busy subsystem is that you will often end up getting a lot of mail that requires reading and handling which in turn requires sending a lot of mail out in reply. Some of that requires thought and careful consideration but a lot of it is quite routine and (perhaps surprisingly) there is often more challenge in doing a good job of handling these routine messages. For a long time I used to hand write every reply I sent but the problem with doing that is that sending the same message a lot of times tends to result in the messages getting more and more brief as the message becomes routine and practised. Your words become more optimised and if you’ve stopped thinking about the message before you’ve finished typing it then there’s a desire to finish the typing and get on to the next thing. This is I think a lot of the reputation that kernel maintainers have for being terse and unhelpful comes from – messages that are very practised for someone sending them all the time aren’t always going to be obvious or helpful for someone who’s not so intimately familiar with what’s going on. The good part of it is that everyone is getting a personalised response and it’s easy to insert a comment about that specific situation when you’re already replying but it’s not clear that the tradeoff is a good one. What I’ve started doing instead for most things is keeping a set of pre-written paragraphs for common cases that I can just insert into a mail and edit as needed. Hopefully it’s working well for people, it means the replies are that bit more verbose than they might otherwise be (mainly adding an explanation of why a given thing is being asked for) but can easily be adapted as needed. The one exception is the “Applied, thanks” mails I used to send when I apply a patch (literally just saying that). Those are now automatically generated by the script I use to sync my local git repository with kernel.org and very much more verbose: From: Mark Brown To: ${CCS} Cc: ${LIST} Subject: ${SUBJECT} In-Reply-To: ${MSGID} The patch ${TITLE} has been applied to the ${REPO} tree at ${URL} ${BRANCH} All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. (unfortunately this bit seems to be something that it’s worth pointing out) If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark (the script does try to CC relevant lists). As well as giving people more information this also means that the mails only get sent out when things actually get published to my public repositories which avoids some confusion that used to happen sometimes with people getting my replies before I’d pushed, especially when I’d been working with poor connectivity as often happens when travelling. On the down side it’s very much an obvious form letter which some people don’t like and which can make people glaze over. My hope with this is to make things easier on average for patch submitters and easier for me, f[...]



Full quoting

2009-07-30T22:42:48Z

There’s a long standing idea tha one should make an effort to trim out text from the original which is not germane to the new content in your reply. This is not just a bandwidth thing, it’s also about decreasing the effort required for the readers to parse the message – to locate the new […]

There’s a long standing idea tha one should make an effort to trim out text from the original which is not germane to the new content in your reply. This is not just a bandwidth thing, it’s also about decreasing the effort required for the readers to parse the message – to locate the new text and refresh their memory of the relevant bits of the conversation. Unfortunately it seems that more and more people aren’t doing the cutting.

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!




GMail UI issues

2009-06-21T10:48:37Z

I read a lot of e-mail, mostly for Linux related purposes. Normally people use well behaved e-mail clients and everything is presented in a fairly standard fashion but there’s some that often stick out like a sore thumb. The obvious one is Outlook, which has well known idiosyncracies but which some companies force their employees […]

I read a lot of e-mail, mostly for Linux related purposes. Normally people use well behaved e-mail clients and everything is presented in a fairly standard fashion but there’s some that often stick out like a sore thumb.

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 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.




Buffer overflows ahoy

2009-02-18T10:50:36Z

I may be wrong on this but it looks like Microsoft SMTP clients (at least Windows Mail and Outlook) don’t like being sent a large volume of SSL certificate information when opening a TLS connection. They appear to assume that the data they are being sent is malformed and assume that STARTTLS failed, continuing with […]

I may be wrong on this but it looks like Microsoft SMTP clients (at least Windows Mail and Outlook) don’t like being sent a large volume of SSL certificate information when opening a TLS connection. They appear to assume that the data they are being sent is malformed and assume that STARTTLS failed, continuing with an unencrypted  SMTP dialogue.

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 Clientrn"

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.




Upgrading crm114

2009-02-15T00:01:44Z

When upgrading from older crm114 releases and trying to retain your existing configuration it is important to check that all the configuration options that the new version expects to be set have been set. While some will cause errors if they’re omitted others will appear to work but will cause unwanted behaviour at runtime. For […]

When upgrading from older crm114 releases and trying to retain your existing configuration it is important to check that all the configuration options that the new version expects to be set have been set. While some will cause errors if they’re omitted others will appear to work but will cause unwanted behaviour at runtime. For example, omitting good_threshold and spam_threshold will cause everything to be flagged as spam in X-CRM114-Status even though the classifier is working well.

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.




Apple Mail and format=flowed

2008-08-30T11:25:04Z

There’s one thing that the Apple Mail client gets right which I’ve never seen anything else try to do – the way it formats messages. Most mail clients seem to offer plain text and HTML as user selectable options and do exactly what they’re told regardless of the content of the message. If HTML is […]

There’s one thing that the Apple Mail client gets right which I’ve never seen anything else try to do – the way it formats messages. Most mail clients seem to offer plain text and HTML as user selectable options and do exactly what they’re told regardless of the content of the message. If HTML is enabled they always send a mail with both text/plain and text/html renditions of the message. Normally the plain text version is a fixed, 80 column version. This is wasteful of bandwidth, especially since very few users actually use any formatting at all, and means that mail programs that don’t do HTML have to treat the mails as though the fixed layout the sending system chooses is important even when it results in poor layout (for example, on mobile devices with small screens).

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.




Paging Doctor Grumpy

2008-08-13T16:49:05Z

Please, folks, when emailing the same question to multiple people or places send a single email with multiple recipients. Don’t send separate mails to each destination – at best you’ll waste people’s time, at worst you’ll irritate them. There are a few exceptions, mostly to do with confidentiality, but they really are pretty rare – […]

Please, folks, when emailing the same question to multiple people or places send a single email with multiple recipients. Don’t send separate mails to each destination – at best you’ll waste people’s time, at worst you’ll irritate them. There are a few exceptions, mostly to do with confidentiality, but they really are pretty rare – especially for free software.

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




Security here we come

2007-12-30T20:15:11Z

The IMAP client provided with the version of Symbian on my phone has an interesting way of verifying certificates used for encrypting IMAP connections. 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 […]

The IMAP client provided with the version of Symbian on my phone has an interesting way of verifying certificates used for encrypting IMAP connections.

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.




Spam backscatter

2007-09-16T11:56:45Z

Over the past couple of weeks I’ve started getting messages like this from the SourceForge: 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 […]

Over the past couple of weeks I’ve started getting messages like this from the SourceForge:

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.




In plain sight

2007-02-06T19:53:55Z

Even worse than the usual multipart/alternative messages with a contentless text/plain part are messages like that when there quite clearly is a text/plain version of the message (for example, as another option when you sign up for a list) but it’s not been included and this unhelpful “error” has been included. This annoys me: my […]

Even worse than the usual multipart/alternative messages with a contentless text/plain part are messages like that when there quite clearly is a text/plain version of the message (for example, as another option when you sign up for a list) but it’s not been included and this unhelpful “error” has been included. This annoys me: my text mode mail reader is perfectly capable of coping with both multipart/alternative and (via whatever run-mailcap gives it) text/html messages; the error here is entirely in the sending software. It should either include the text/plain version which the sender is already going to the trouble of producing as an alternative in a multipart message or just not bother with the alternative at all.

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.