Mail Wrapping

[steve]

Le 14-08-2010, à 15:41:06 +0200, Dr. H. Nikolaus Schaller (hns at goldelico.com) a écrit :

> > Please people stop spamming about line length.
> > If you MUA is so good then ask it to automatically split long lines :-p
> 
> I agree that we should not spam - but IMHO this was raised as a serious
> problem.

Serious no, just courtesy.
 
> I could live with the idea that everyone uses a MUA that can
> wrap lines when reading and displaying long lines. But it appears there
> are systems out there that can't (which I did not yet know). 

How does *your* mua display your own long lines? Does it wrap the lines
to a predefined length? Or do you see them as you type them?

> And I am asked to solve their display problem on the senders side

I'm not obliging you at all, it was just a nice remark and I felt I
could share it with you because through your prose I felt someone open
to remarks. That's all.

> (although I have much better things to do)...

I'm sure of that! (I don't write a lot here, but I read nearly
everything).

> Am 14.08.2010 um 09:28 schrieb Matthias Apitz:
> 
> > El día Saturday, August 14, 2010 a las 08:34:51AM +0200, Dr. H. Nikolaus Schaller escribió:
> > 
> >>> Nikolaus, couldn't you wrap your lines to something more standard (72 or
> >>> so ?) Thanks, I like reading your prose, but those long lines are really
> >>> irritating.
> >> 
> >> Hi Steve,
> >> 
> >> there are different opinions if the 80 char line wrapping of mail is standard or some
> >> old-fashioned relict from the 80ies. I have tried to find out what it is but it appears
> >> to be a problem with some MUAs not correctly handling RFC 2646.
> >> 
> >> Here is also some discussion about mailman being responsible or not:
> > 	....
> > 
> > Hi Nikolaus,
> > 
> > It is the responsibility of your MailUserAgent to wrap lines correctly
> > around column 72. You are using Apple Mail (2.1081). If this can not do
> > this, just use another MUA or another system providing correct software.

He said it (also) :-)

> Before we start fingerpointing on any client we are using, let's do a little more research.
> 
> http://mailformat.dan.info/body/linelength.html
> 
> quotes RFC 2822 (the successor to RFC 822):
> 
>   "There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF."
> 
> I.e. lines more than 78 characters are *not* forbidden. From this I conclude
> that a mail recipient must cope with that. If not, the client is broken.

No. Mutt displays long line but that's not a reason for it to be broken. 

I repeat, it is easier for humains to read lines not excedding 80
caracters, after you get tired and your concentration decreases. So as
the writer, your goal is to catch your readers attention and one way to
do it, is to wrap lines to a descent lenght (between 72 and 80
caracters). 

> And, I conclude that it is not a rule for writing or displaying mails - just
> for transferring them over SMTP without making buffer overflows.

I don't care what the MTA does (at this point).

> Now let's look into the plain code my MUA is sending. Here is an example:
> 
> > Hi Steve,
> > 
> > there are different opinions if the 80 char line wrapping of mail is standa=
> > rd or some
> > old-fashioned relict from the 80ies. I have tried to find out what it is bu=
> > t it appears
> > to be a problem with some MUAs not correctly handling RFC 2646.
> > 
> > Here is also some discussion about mailman being responsible or not:
> > 
> 
> So Apple Mail *is* correclty sending wrapped lines according to RFC.

You're kidding I hope? Second line, there is only three words, same on
fourth line. The text presented like that just sucks.

> I do not excactly know what the rules are to interpret the = signs at the
> end of the line. I guess it has to do with 
> 
> Mime-Version: 1.0 (Apple Message framework v1081)
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> A little more search shows this comes from RFC 2045 (MIME) on page 19 (Soft Line Breaks).
> 
> From this I conclude that the mails my client sends are correct (according
> to the standard).

I think your conclusion is wrong.

[...] 

Kind regards

--
steve