SetLE, Mime headers.

Swift Mailer is a fantastic library for sending email with php. Discuss this library or ask any questions about it here.

Moderators: Chris Corbyn, General Moderators

Post Reply
chuckl
Forum Commoner
Posts: 61
Joined: Wed May 23, 2007 7:36 am

SetLE, Mime headers.

Post by chuckl »

Couple of questions on message composition -

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 LF
Is this handled automagically by Swiftmailer, or left as an exercise for the student? i.e. should it be explicitly set with setLE depending on the transport selected?

Secondly, 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>
followed by the from, spamkiller X headers, and the preamble message about outdated mail readers.
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:

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.
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?

Rgds,

Chuck
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

You have to set the LE yourself if you're using sendmail -t. I *strongly* urge you not use sendmail -t though. It's *definitely* not going to work properly on some systems, I've never tested it fully and the code simply is not developed to work properly with it. I experimented with it briefly during the conversion from version 2 to version 3 but decided not to pursue it after reading Exim's notes about how it goes against the RFCs for Bcc recipients and Exim does not believe people should use it (it's not consistent across platforms which is why mail() varies so drastically). It says in my documentation that you shoud not use "-t" mode in a production environment and that it probably won't work properly ;)

Swift should be using 8bit where needed and 7bit if not needed. You may see a 7bit header being set if the MIME parts are being encoded as Base64 or quoted-printable. Thinking about it now, sub-parts may not affect the outer parts in my logic, although it's easy to change that myself.

It's nice to have a critical set of eyes on my code, thanks :)
chuckl
Forum Commoner
Posts: 61
Joined: Wed May 23, 2007 7:36 am

Post by chuckl »

It's nice to have a critical set of eyes on my code, thanks
To paraphrase 'never attribute to malice..', Never attribute to diligence that which may be explained by laziness and self interest...

Thanks for the info, that was most useful, as I've found that the more compliant an email message is, the less likely it is to be marked as spam. (disregarding SPF records and other domain setup stuff).

On the 'sendmail -t' front, while Exim is a fine product, I'd urge some caution in relying too much on the comments in the notes. I've found that they are a bit too similar to the Gnome developers in taking a purist approach. There's a PURIST_MODE On, and the debate stops, when what is often needed is not what is decreed, but what is sensible.
'sendmail -t -i' is the default setting on so many mail systems that I believe it is very necessary to support it, imperfect though it may be. Particularly when many hosting services bar any user permissions on sendmail, so you cannot change the flags in any way. viz. lstat problems on many systems.
I also agree that a wise solution is not to use sendmail, but again, many hosting co's. just about set this in stone as well, by blocking port 25.
So my opinion, for what it's worth is that 'sendmail -t -i' should be consciously supported, even if the implementation is not stnadardised. It's better than no mail at all. I think I'm right in saying that the '-i' is an attempt to get around '.\n' truncation problems and means 'do not treat .\n as end of file?'

On the MIME headers side, I assume this would be set in the 'multipart alternative by a '->setAttribute'?
The examples are a bit full of "foo" and "bar" to be sure.

Rgds,

Chuck
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

chuckl wrote:
It's nice to have a critical set of eyes on my code, thanks
To paraphrase 'never attribute to malice..', Never attribute to diligence that which may be explained by laziness and self interest...

Thanks for the info, that was most useful, as I've found that the more compliant an email message is, the less likely it is to be marked as spam. (disregarding SPF records and other domain setup stuff).

On the 'sendmail -t' front, while Exim is a fine product, I'd urge some caution in relying too much on the comments in the notes. I've found that they are a bit too similar to the Gnome developers in taking a purist approach. There's a PURIST_MODE On, and the debate stops, when what is often needed is not what is decreed, but what is sensible.
'sendmail -t -i' is the default setting on so many mail systems that I believe it is very necessary to support it, imperfect though it may be. Particularly when many hosting services bar any user permissions on sendmail, so you cannot change the flags in any way. viz. lstat problems on many systems.
I also agree that a wise solution is not to use sendmail, but again, many hosting co's. just about set this in stone as well, by blocking port 25.
So my opinion, for what it's worth is that 'sendmail -t -i' should be consciously supported, even if the implementation is not stnadardised. It's better than no mail at all. I think I'm right in saying that the '-i' is an attempt to get around '.\n' truncation problems and means 'do not treat .\n as end of file?'

On the MIME headers side, I assume this would be set in the 'multipart alternative by a '->setAttribute'?
The examples are a bit full of "foo" and "bar" to be sure.

Rgds,

Chuck
Hosts which have made it difficult to use sendmail should still allow the use of the NativeMail connection which wraps mail() ;) Given that it won't be too much hassle to fully test and integrate the "sendmail -t" functionality I guess I could finish that off. The -i does make sure 'CRLF . CRLF' doesn't end the message, although Swift has code to prevent this in any case (replace 'CRLF .' with 'CRLF ..').

The charset is indeed set with a setAttribute() call, except it's wrapped around a method called setCharset() to make it more readable.

:)
Post Reply