In the comments above fixLE in Encoder.php, you note
Code: Select all
* Fixes line endings to be whatever is specified by the user
* SMTP requires the CRLF be used, but using sendmail in -t mode uses LFSecondly, I've noticed that all test messages sent have the following multipart/alternative header:
Code: Select all
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="_=_swift-131614953946cf49c59e2e71.26362164_=_"
Content-Transfer-Encoding: 7bit
Message-ID: <20070824211237.11718.939375672.swift@www.test.mydomain.com>The various message body parts then follow between boundaries, with their types and transfer encoding.
However, rfc 2045 has a throwaway line on multipart/alternative Content transfer encoding as follows:
and the message body parts are all happily set to 8bit, whether it be text/plain html or whatever. Is the 7bit transfer encoding in the initial multipart/alternative in the header to cover the preamble, or should I be explicitly setting it somewhere to more accurately reflect the message part encoding?
It should also be noted that, by definition, if a composite entity
has a transfer-encoding value such as "7bit", but one of the enclosed
entities has a less restrictive value such as "8bit", then either the
outer "7bit" labelling is in error, because 8bit data are included,
or the inner "8bit" labelling placed an unnecessarily high demand on
the transport system because the actual included data were actually
7bit-safe.
Rgds,
Chuck