Posted by Rik Wasmus on 11/24/07 14:03

On Sat, 24 Nov 2007 14:34:21 +0100, Matthew <matthew@spamkiller.com> wro=
te:
> John Dunlop emailed this:
>> C. (http://symcbean.blogspot.com/):
>>> No - that's SMTP which is a specific transport mechanism for email
>>> (actually its a whole family of protocols but lets not go there) its=

>>> up to the MUA ('mail' command on Unix or the SMTP implementation
>>> within PHP for |MSWin) to **convert** the message to a suitable form=
at
>>> for the MTA, which may in turn encode the message in a different
>>> format depending on the carrier protocol.
>> Right.
>>
>>> Perhaps historically the SMTP implementation in PHP couldn't
>>> accomodate this.
>>>
>>> If you sniff the SMTP connection you'll see that long lines do get
>>> wrapped - but the original message is restored when it comes out the=

>>> MUA at the other end.
>> I wonder where PHP's figure 70 came from? If long lines do get
>> wrapped but you still recommended a limit, would you not recommend
>> 78, in line with the transfer protocol?
>> On the other note, line endings seem a bit messy: \n for the message=

>> body but \r\n for headers, whereas the transfer protocol demands \r\n=

>> across the board. Then, I suppose, the whole business of line ending=

>> conventions is messy.
>
> It seems a strange for PHP to place an extra limitation like this on =

> line lengths.

PHP doesn't. PHP informs you of a limitation older clients/servers may =

have.

> It's not really a problem as line wrapping at 70 chars looks perfectly=
=

> neat in all email clients I've ever used. As it happens between 70 and=
=

> 75 chars are the settings I've always used when manually setting word =
=

> wrap in my email client's options.
>
> My question was why PHP places this restriction at all. It's not even =
=

> sending the mail itself anyway, just passing the email to 'sendmail',

Euhm, mostly passing it to sendmail. Others are possible, and under =

Windows an external SMTP server.

> surely then it should simply be concerned with whatever line length =

> restrictions 'sendmail' imposes.
>
> I've just looked in the sendmail manual which says it conforms to RFC =
=

> 821, this is the SMTP standard, URL - http://www.ietf.org/rfc/rfc0821.=
txt
>
> The relevant bit of the RFC 821 SMTP standard says:
>
> "Text Line - The maximum total length of a text line including the =

> <CRLF> is 1000 characters (but not counting the leading dot duplicated=
=

> for transparency)."
>
> AFAICT SMTP does not place any further restrictions on message body li=
ne =

> lengths (though other fields do have text length restrictions such as =
=

> the reply line being a max. of 512 chars). I can't find any reference =
in =

> the protocol to message body lines (or any other lines) being further =
=

> limited to either 70 or 78 characters.

RF2822 states:
'Each line of characters MUST be no more than 998 characters, and SHOULD=
=

be no more than 78 characters, excluding the CRLF'

It's the difference between MUST and SHOULD.

'The more conservative 78 character recommendation is to accommodate the=
=

many implementations of user interfaces that display these messages whic=
h =

may truncate, or disastrously wrap, the display of more than 78 characte=
rs =

per line, in spite of the fact that such implementations are =

non-conformant to the intent of this
specification (and that of [RFC2821] if they actually cause information =
to =

be lost). Again, even though this limitation is put on messages, it is =

encumbant upon implementations which display messages to handle an =

arbitrarily large number of characters in a line (certainly at least up =
to =

the 998 character limit) for the sake of robustness.'

So, there may be applications out there that can't handle long lines ver=
y =

well, they should try though. So most email applications are robust enou=
gh =

to handle longer lines, yes.

I've had buggy POP3 servers in the past (that's over no thankfully), I =

remember using Windows and telnetting to a POP3 server to check =

email/check queue-busting messages. So not a slick GUI at all, just a =

console. The wrapping is very welcome then, certainly because I can use =
a =

'TOP msg# #lines' command, where #lines are the number of lines to =

display. I'd really hate it when I just want to see the first 5 lines to=
=

check the message, and it turns out that's 5000 characters.

> With that said, why is PHP concerned with further limits?

It isn't try to send ridiculously long lines. PHP will not complain. The=
=

writers of the manual were kind enough to inform you about conventions. =
=

Afaik, it's not enforced in any way.


> Why not just let the user enter their own newlines, the programmer add=
a =

> CRLF at 998 chars if necessary, and let the recipient's email client =

> handle line wrapping as per it's own settings/user options?

For this kind of thing, we have the format=3Dflowed property =

(<http://www.ietf.org/rfc/rfc2646.txt>). Compliant readers will 'reflow'=
=

the message according to 'soft' (i.e. wrapped) and 'hard' linebreaks. Th=
is =

is especially great on usenet, as it often can and will 'reflow' quotes =
=

(check the example in the txt-file linked above). So, you can have the =
=

best of both worlds: a reasonable human readable limit of characters on =
a =

line as raw source/non-compliant readers/console reading, and a nice =

reflow of text in compliant readers with or without GUI's. All without =

resorting to long lines or HTML as mime type :)
-- =

Rik Wasmus

[Back to original message]