On Mon, December 16, 2013 00:38, waldo kitty wrote: > On 12/15/2013 3:06 PM, Johannes W. Dietrich wrote: . . >> Apple Mail doesn't seem to be the only software that doesn't know what >> to do >> with this type of encoded data. The problem seem to affect the list >> processor, >> too. See >> http://lists.freepascal.org/lists/fpc-pascal/2013-December/040336.html >> in the archive for reference. > > FWIW: the displayed block at the URL given decodes perfectly with the MIME > decoding URL i gave previously... > > i have a sneaking suspicion that some are expecting certain control lines > to be > in use when they are not required for the given context... but then i'm > still > learning this MIME stuff and have only some tools at hand to work with and > base > my understanding on...
As already suggested by Jonas, responding to fpc-other. Sorry, but I believe that you should indeed check the respective RFCs first (and possibly also search some information about what mail servers may do when receiving an e-mail with message encoding not supported by their configuration in order to understand what may cause differences with different recipients). In any case: 1) RFC 2045 states that 7-bit "encoding" (i.e. no encoding necessary due to using only lower part of ASCII table aka us-ascii character set) is the default assumed if no other information about content encoding is provided (i.e. encoding the message using base64 without specifying this explicitly is invalid and any client doing this based on some heuristic methods of guessing the encoding would be breaking the RFC defined behaviour). 2) As also mentioned in the RFC mentioned above, the SMTP message format (RFC 821) requires all messages to be in us-ascii. Many e-mail clients provide possibility to allow 8-bit messages in their configuration (and some others might even do it silently by default). Even worse, some e-mail clients allow including non-encoded characters outside of us-ascii without signalizing that the encoding is in fact 8-bit (i.e. not conforming to the original SMTP message format). However, anybody allowing these 8-bit characters without encoding outside his own controlled environment (e.g. within a company) is in a risk that any of SMTP servers encountering such messages might enforce the strict rules of RFC 821 format and encode the message differently according to their own selection. This means that different recipients may receive the same message in different format. Obviously, proper headers should be added during this encoding - Jonas suggested that this might have worked wrongly in this case. Tomas _______________________________________________ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
