[Mailman-Users] Seeking Email Client Recommendation - Specific use scenario

[Mark Sapiro]

On 5/19/2010 3:02 PM, Drew Tenenholz wrote:
> 
> Here are my specific client software needs:
> 
> 1) a cross-platform client (Mac & Windows; Mac 10.5 & up, Windows XP &
> Windows 7)
> 2) capable of sending "plain-text" messages (see below)
> 3) capable of sending to mailman in many languages (e.g. English,
> French, Spanish, Portuguese, Russian, Thai, Khmer, Lao, Chineese),
> without munging the characters such that they come out incorrectly in
> the list messages
> 4) reasonably simple to configure and maintain for a user base of 10-40
> users located all over the world
> 5) capable of off-line message creation (so not solely web-mail based
> solutions)


Two others have recommended T-bird and I agree it meets the
requirements. Also, it is easy to configure custom headers with T-bird
such as the Approved: header that may be used for posting to announce lists.


> One thing I'm seeing is that French accents sent from MS-Entourage (Mac
> version of Outlook) end up with surrounding spaces in the SUBJECT LINE
> ONLY ( e.g. pand é mique instead of pandémique) while my very old &
> trusty Eudora 6.2.4 has absolutely no problems with the same text; go
> figure!


This may be a problem with the receiving MUA rather than the sender,
although both may be not doing the right thing.

When RFC 2047 encoding headers like Subject, The word pandémique should
be encoded for example using iso-8859-1 and quoted printable encoding as
"=?iso-8859-1?Q?pand=E9mique?=". I.e. the whole word should be encoded
in one "encoded-word". Some MUA's do not do this properly. If the MUA
encodes the word as "pand =?iso-8859-1?Q?=E9?= mique", the encoding MUA
is wrong and the decoding MUA would be correct to insert spaces. On the
other hand, the string "pand=?iso-8859-1?Q?=E9?=mique" is not a valid
encoding at all as an "encoded-word" must be delimited by whitespace.
Because of this, white space between adjacent encoded words as in
"=?iso-8859-1?Q?pand?= =?iso-8859-1?Q?=E9?= =?iso-8859-1?Q?mique?="
should be ignored, but not all decoding MUAs will ignore it.

This is further complicated by the fact that Mailman may alter the
encoding of the Subject: header when adding the subject_prefix, but as
far as I know, nothing Mailman does will insert spaces, although it may
lose the space between the subject_prefix and the rest of the subject.

[...]
> 
> It would be helpful if this email client had a setting to NOT line-wrap
> messages, there is this whole long editing and proofing process before
> sending out the announcement (all managed by a closed [soon to be
> Mailman] list), and line-wrapping becomes a real PITA.


In T-bird, it's an "advanced" option, but it can be set.


[...]
> 
> The off-line message creation is necessary because frankly we have
> people who a are off the grid a lot (either travelling or in places
> without any meaningful internet access).  Also, the posts require a good
> deal of thought, formatting, and correction.  Having a tiny little
> composition window is just not going to cut it. What some people do now
> is literally that: 'cut' from the email application, 'paste' into
> MS-Word for corrections, then cut/paste back into email & send. (Talk
> about your encoding glitches....)


T-Bird can compose off line and send later (as can many other clients).
You can make the composition window as big as you want.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan