[pmmail-list] Thunderbird vs. PMMail (was: alright, I've had enough ...)

[L.Willms]

On Wed, 18 May 2005 12:58:43 -0400, Steve Marvin wrote:

> I don't see anywhere in the rfc's applicable to mime that rule out the
> "Content-Transfer-Encoding: base64". 
 
   It is not so clear in the current version, yet clearer in the older 
one (RFC 1521). 

> base64 is one of the listed encoding mechanisms in rfc2045 
> and in fact it designates this mechanism as the default handling 
> method for binary data. 

  The reason given is that UA (User Agent) programs, i.e. eMail clients, 
would have problems to process recursively nested encodings. I think 
that is wrong, and this requirement should be dropped. 

----schnipp--from RFC 2046---------------------

> 5.2.1.  RFC822 Subtype
> 
>    A media type of "message/rfc822" indicates that the body contains 
an
>    encapsulated message, with the syntax of an RFC 822 message.
>    However, unlike top-level RFC 822 messages, the restriction that 
each
>    "message/rfc822" body must include a "From", "Date", and at least 
one
>    destination header is removed and replaced with the requirement 
that
>    at least one of "From", "Subject", or "Date" must be present.
> 
> 
> 
> Freed & Borenstein          Standards Track                    [Page 
28]
> 
> RFC 2046                      Media Types                  November 
1996
> 
> 
>    It should be noted that, despite the use of the numbers "822", a
>    "message/rfc822" entity isn't restricted to material in strict
>    conformance to RFC822, nor are the semantics of "message/rfc822"
>    objects restricted to the semantics defined in RFC822. More
>    specifically, a "message/rfc822" message could well be a News 
article
>    or a MIME message.
> 
>    No encoding other than "7bit", "8bit", or "binary" is permitted for
>    the body of a "message/rfc822" entity.  The message header fields 
are
>    always US-ASCII in any case, and data within the body can still be
>    encoded, in which case the Content-Transfer-Encoding header field 
in
>    the encapsulated message will reflect this.  Non-US-ASCII text in 
the
>    headers of an encapsulated message can be specified using the
>    mechanisms described in RFC 2047.
-----------schnapp----------------

> It would seem to be a problem of Thunderbird's if it cannot 
> handle base64.

   It can, but insisting on the rules of the RFCs should not go so far 
as to refuse to do what other email clients can do. 


Yours, 

Lüko Willms
-----------------------------------------------
Frankfurt/Main