TYPO3 Core

This problem is just a problem in our "mail()" hook right? Using SwiftMail routines to generate Mails + Attachments, you'll never come to these problems? This is unclear by your report, please clarify! Powermail could adapt to use SwiftMailer to overcome the problem in future versions, couldn't it?

Isn't there a way to pass "an unprocessed" body to SwiftMail? The easiest would be to pass things "as is" to Swiftmail and let the mail go out as it was doing before, and not try to "RFCize" it with extra work. This is getting too ugly already.

So as soon as t3lib_html mail passes headers and a body to SwiftMail, only process the headers which we need in order to send the mail (Receipients) but pass the headers like "Content-type", etc and the whole Body "as is" to the Mail.

It's a problem in our "hook" t3lib_mail_SwiftMailerAdapter. Directly using Swift Mailer is the solution, but we can't expect all extensions to be updated when 4.5.0 is released.

I haven't found a way to inject a completely processed body into Swift Mailer. When sending a mail message Swift Mailer will check all settings for encoding, charset, content-types, etc. and process the parts (body, other parts, attachments). It's a pretty complex construction inside Swift Mailer classes.

Yes, of course SwiftMailer won't allow the sender to create "non-RFC-conforming" mails, that's the reason for it at the first place. :)

Maybe we could create a "Swift_Mime_Message" which is not RFC conformant and which we can pass to our Transports instead, thus not passing all the controls a regular Swift_Message does. Unfortunately Swift_Message is not an interface, but a concrete class, so we cannot "replace" it with some other class.

I fear that if we start doing too much crazy parsings, we end up with other failures that keep our code getting thicker and thicker just for the sake of backwards compatibility.

An easy alternative would be:

- make the t3lib_htmlmail hook configurable (on/off) via All Configuration switch,
- users either use the hook to make their system send mails through SwiftMailer transport; or they keep the "old system" (going through "mail()" only) if something doesn't work (powermail etc).

This gives time for extensions to move to SwiftMailer, and make them aware of the benetifs, and doesn't require us to do so much work for the transition.

Attached the list of places where t3lib_utility_Mail and t3lib_htmlmail are used in the core.

Thanks for the summary Jigal. Here is my proposed plan of suggested solutions for the final release:

t3lib_div::encodeHeader($line, $enc = 'quoted-printable', $charset = 'iso-8859-1') {
=> make it use
- Swift_Mime_HeaderEncoder_Base64HeaderEncoder
- Swift_Mime_HeaderEncoder_QpHeaderEncoder

t3lib_div::plainMailEncoded($email, $subject, $message, $headers = '', $encoding = 'quoted-printable', $charset = '', $dontEncodeHeader = FALSE)
=> make it use SwiftMail instead (have to consider the desired encoding...)

t3lib_div::sysLog
=> make it use SwiftMail instead (easy)

class.tx_install.php
=> change the switch to test via t3lib_htmlmail and without it and change it to test via SwiftMail and with t3lib_utility_mail::mail() instead

t3lib_beuserauth::emailAtLogin
=> change if to use SwiftMailer (easy, but have to consider more potential "headers")

t3lib_userauthgroup::checkLogFailures
=> make it use SwiftMail instead (easy)

t3lib_formmail is a subclass of t3lib_htmlmail
=> adapt TSFE->sendFormmail to use SwiftMail instead
=> remove "extends t3lib_htmlmail" so that it works stand-alone
(migrate the addAttachment)

fe_adminLib.inc
=> ignore it...

tx_linkvalidator_tasks_validate
=> issue on forge to make it use SwiftMailer, with untested patch:
http://forge.typo3.org/issues/12344

tx_scheduler_testtask
=> I have a patch for this already, will create the RFC

t3lib_div::encodeHeader($line, $enc = 'quoted-printable', $charset = 'iso-8859-1') {
JvH: This should not be used anymore when sending stuff with Swift Mailer; everything is encoded automagically. The adapter will decode the headers, so there's really no point in changing this.

t3lib_div::plainMailEncoded($email, $subject, $message, $headers = '', $encoding = 'quoted-printable', $charset = '', $dontEncodeHeader = FALSE)
=> make it use SwiftMail instead (have to consider the desired encoding...)
JvH: this shouldn't be used at all with Swift Mailer. Because it expect to receive processed headers it's better to let the adapter handle it.

t3lib_div::sysLog
=> make it use SwiftMail instead (easy)
JvH: changed

class.tx_install.php
=> change the switch to test via t3lib_htmlmail and without it and change it to test via SwiftMail and with t3lib_utility_mail::mail() instead
JvH: changed to use Swift Mailer and the 'old' function
There are still tests left for the PHP configuration of the mail() function, but these are kind of useful when you disable the adapter

t3lib_beuserauth::emailAtLogin
=> change if to use SwiftMailer
JvH: changed (2 calls)

t3lib_userauthgroup::checkLogFailures
=> make it use SwiftMail instead (easy)
JvH: changed

t3lib_formmail is a subclass of t3lib_htmlmail
=> adapt TSFE->sendFormmail to use SwiftMail instead
=> remove "extends t3lib_htmlmail" so that it works stand-alone
(migrate the addAttachment)
JvH: changed it only uses Swift Mailer

fe_adminLib.inc
=> ignore it...

tx_linkvalidator_tasks_validate
=> issue on forge to make it use SwiftMailer, with untested patch:
http://forge.typo3.org/issues/12344 [^]

tx_scheduler_testtask
=> I have a patch for this already, will create the RFC

Authors of Powermail (in2code) and Direct Mail were contacted and both will look into supporting Swift Mailer in one of the coming versions.

Committed to trunk, rev 10227... we got rid of t3lib_htmlmail, finally! ;) Thanks Jigal for your tremenduous work on that, and also Susanne for testing!