Hi Roberto,
> http://www.unicode.org/faq/utf_bom.html#28
> See No. 4 at the bottom.
That is the reason I started this issue (unfortunately I have had no time to
read any older maillist messages). Thus is explicitly wrote that BOM "should
not" be used at beginning of stream if it is already known. However, as
understood, some problematic version of Outlook doesn collect charset
properly, which was the reason for interting BOM. Instead forcing BOM as
soultion, I would try to investigate a bit further what is exact cause of the
bug in that specific version of Outlook. Perhaps it require charset
casesensitive (UTF-8, utf-8, or even Utf-8) or even "UTF-8"/"utf-8". At least
any e-client pretending to be "correct", should support at least RFC
suggested form.
RFC-3629 also explicitly forbid use of BOM if charset is already known:
"A protocol SHOULD also forbid use of U+FEFF as a signature for
those textual protocol elements for which the protocol provides
character encoding identification mechanisms, when it is expected
that implementations of the protocol will be in a position to
always use the mechanisms properly. This will be the case when
the protocol elements are maintained tightly under the control of
the implementation from the time of their creation to the time of
their (properly labeled) transmission.
"
Following this, non of e-client do not use BOM when composing message, except
these relied on synapse.
> In the end, I just modified the synapse code to add a property
> "WantBOM" which was False by default. But this means maintaining it
> across newer Synapse versions.
I already coded from ground several protocols and using it instead of
synapse's (using only synapse socket for now), simplifying methods. In
TSZSMTPClient I implemented my own existed solutions to compose messages,
where I also have implemented simple logic to determinate proper Content-Type
for message header depending on existed bodyparts... Etc...
Using my own protocol clases it is avoided maintaining problem and prevented
eventually unwanted feature (as is BOM here). In the same time, I using my
protocols which have simplified approach according to my needs (according to
RFC specifications), resulting in better usage.
That is all about the issue.
Sasa
--
www.szutils.net
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
synalist-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/synalist-public
