|
|
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
Navigation:
[Reply to this message]
|