Hi Jan-Erik

Only slightly off this diverging topic... about e-mail "standards".... 
One standard is to reference the ID of the original mail when replying 
to a message.

by way of example, your message that I am replying to is identfied by:

Message-ID: <30505024.1153004208237.JavaMail.tomcat@pne-ps3-sn1>

The mail I am writing now will be given a Unique ID by my ISP as it is received.

My message will also have a "References" indicator.
It will look like:

References: <30505024.1153004208237.JavaMail.tomcat@pne-ps3-sn1>

This will enable threaded reading of messages. 

The page http://cr.yp.to/immhf/thread.html has a good intro to the issue.

As it happens, your mail software "CP Presentation Server" does not 
honour the References (nor the In-Reply-To) headers, and thus, your 
e-mails *always* fail to thread properly.

You are pretty much unique on this list for having a non-compliant mail 
client.

I find this to be far more irritating than line-length.

Anyways, even the microsoft mail clients (outlook*) honour the protocol. 
Perhaps this can be taken up with your support people.

Rolf

Jan-Erik Soderholm wrote:
> Gerhard Fiedler wrote :
>
>   
>> What I never understood is why mail servers have to peek into 
>> my message lines. They shouldn't really care about what is
>> there, where the CRs and/or LFs are -- they should just pass
>> it on, please, the way it was sent...
>> Does anybody know why mail servers look for line ends in 
>> messages? What are they trying to find?
>>     
>
> Since the smtp protocol is *text-based* (that is works by
> sending *lines* using the printable part of the US-ASCII
> character set), there have to be some standard.
>
> It's not a full 8-bit binary "channel" where you can send
> just about anything.
>
> Since the smtp protocol is based on sending *lines*, I guess
> the servers *have* to listen for EOL's. How would they
> keep in synk with each other if not ?
>
> Remember, this standard was set when everyone had
> a 24 x 80 char VT100 (or compatible) on their desks. Noone had
> any need to send anything > 80 chars in lenght. So it's was just
> logical for the smtp servers to either "cut" or "split" lines at
> 80 chars.
>
> Later came different encoding systems to enable other files
> then "plain text" to be transferd. Such as uuencode and
> Base64. MIME and so on, but that was long after the base
> smtp protocol was decided.
>
> Jan-Erik.
>
>
>
>   

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