Olin Lathrop wrote in "Re: [PIC] 18F4550 in-circuit serial programming
circuit":

>> you received it truncated to 256 characters, and you thought that this
>> was a non-standard message,
> 
> I never said that, only that it was a bad idea to send long lines.  

Since the problem -- according to you -- seems to be pretty much only your
(or your ISP's) POP3 server (nobody else complained about a truncated
line), maybe the really bad idea is to rely on a broken POP3 server?


> You can argue about standards all you want, but if you want your mail to
> get thru, use 80 character or less lines.

In terms of general usability (not sure this is a concern of yours),
free-flowing text encoded into something like quoted-printable that then
makes the line breaks in the content independent of the line breaks in the
encoded message is the preferred way to go. This then allows everybody to
read the message with the line width that is comfortable for the reader.
Quoted-printable encoding is sent with a line length of max 76
automatically, not affecting the content line length. But then, you don't
like that either... It seems hard to make you happy, other than by
completely giving up on international standards and personal preferences :)


>> The POP3 standard RFC1939 defines that messages are assumed to conform
>> to RFC822.
> 
> But the line length is defined in RFC 821 (STD 10).

The line length of SMTP messages is defined in RFC2821 (superseded RFC821
some time ago). I wrote the phrase above as a response to this comment of
yours: "Actually it is probably the POP3 server that truncated the lines,
not a SMTP server.  I think the POP3 standard does not mention a specific
line length, so implementers can and apparently did chose different
values." 

You kind of stated that you didn't think the SMTP line length as defined in
RFC2821 (which we had already discussed) applies to POP3 (and formally it
doesn't, even though it really doesn't make sense for them to be
different), so I gave you the definition as stated in the POP3 standard. 

>> RFC822 (and RFC2822, which now supersedes RFC822) defines that lines
>> must be limited to 998 characters (excluding the trailing CRLF;
> 
> OK, I wasn't aware of that.  Last time I looked into this, there was no
> RFC2822.

Well... I said that the line length is defined in RFC822 /and/ RFC2822.
RFC822 is dated 1982. "Last time I looked" ?!? :)  This definition of a
line length of 1000 exists since (at least) 1982. If you have done anything
re mail protocols (SMTP, POP3, whatever) in the last 20 years, you could
(should?) have seen that. 


>> So if it really was the POP3 server, there's something to fix. And it's
>> close to home, too, so you know who to talk to.
> 
> With some poking around I could probably find and fix it, but then I
> can't imagine not having something else more important to do for a long
> time to come.

Of course your choice. But then don't complain that you receive emails
truncated by your server...

>> Are you seriously saying that because you don't use these characters,
>> the list server should reject messages using the methods required to
>> transmit them in a standard-conform way?
> 
> Geesh, calm down Gerhard.  That was just a flip response.  

I'm calm. But don't poke me with flip responses :)

> I would love to enforce responsible email formatting 

I'm sure you do. "Responsible" email formatting == OLEF (Olin Lathrop Mail
Format)?  I rather stay with "irresponsible" IETF standards :)

> but I know that would never happen,

I'm sure I'm not the only one who's glad about this :)

> Some of the phancy encoding methods are handled better by clients now,
> but there are still some message I get that when I do a reply it
> switches to some wierd font and generally makes a mess.

I can't recall that happen for many years. Basically, from a compatibility
standpoint, you either received a non-standard message, or your mailer
can't handle some standard elements, or this is a mailer feature you don't
know how to work with. Only you can find that out, and if the problem is
your mailer, then... I wouldn't know why I should change my mailer or its
configuration because of that. Nor why I should not use quoted-printable,
base64, common ISO/Unicode character sets, ...


For example... I think a mailer that switches to quoted-printable
automatically once it detects a paragraph (i.e. content without hard
breaks) of more than 998 characters (or maybe even more than 76 characters)
and transmits that long paragraph with the soft breaks of quoted-printable,
still creating in the client window a free-flowing paragraph of content
without annoying ("irresponsible") hard line breaks does exactly the right
("responsible") thing. Even if that is pretty much the opposite of OLEF:
user-friendly and just works.

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist