[rescue] =?X-UNKNOWN?Q?Re=3A_=5Brescue=5D_Slightly_OT=3A=A0Bad_Cap_Saga?=

[Jonathan C. Patschke]

On Tue, 19 Aug 2008, Lionel Peterson wrote:

> Inserting line breaks imposes a format on the message,

With 'Format="flowed"', your mailer will give you the best of both.  You
may specify lines to the moon and back, should you wish.  Your mailer will
embed "soft" carriage returns at column 79 (or the nearest word break) for
people with mailers that take line-endings literally.  Mailers that
understand 'Format="flowed"' will see where your intended line-endings
are, and will display your lines wrapped to the width of the mailer, or
where you put them, whichever comes first.

The RFC is obtuse and dense, as they are wont to be, but the core of it is
that there are soft CRs and hard CRs.  Soft CRs have a leading space
(which is why lines are wrapped to 79 columns--the dumbest terminals on
the planet will display that correctly).  Hard CRs do not.  Spewing a
'Format="flowed"' message to the terminal with cat will resulting
something legible and nicely-wrapped.  However, for a mailer that
understands what's going on, it knows which CRs it can ignore and which
ones the author intended to be there.

RFC 2646 also specifies the minutiae of how to take all that and handle
nested quotes in a reasonable manner.  It also codifies the signature
separator and a few other Nice Things.  It's tasty with and without
catsup.

> I defer to your email client to present my emails to you in a way that
> suits your tastes.

As seen in your message headers:

   Content-Type: text/plain; charset="us-ascii"

Your mailer is imposing format by omitting 'Format="flowed"'.  By that
omission, your mailer is telling mine "display this text with exactly the
line endings I've specified."

The reason that this is the default behavior should be obvious.
Displaying data exactly as presented, except when given latitude to modify
it, is reasonable behavior for well-behaved software.

> I'm sorry my email format prevents you from enjoying the fruits of my
> random key presses.

This topic seems to keep popping up on this list.  RFC 2646 addresses the
problem in a way that is reasonably non-intrusive for all parties, and is
supported on practically every MUA version released this century.  It
seems a pointless thing to argue about when there's such a widespread
solution that can indulge an author's artistic intent while protecting the
reader from unintentional irritation.

-- 
Jonathan Patschke | "There is more to life than increasing its speed."
Elgin, TX         |                                   --Mahatma Gandhi
USA               |