[TYPO3-core] t3lib_utility_Mail::mail() not using SwiftMailer?
Ernesto Baschny [cron IT]
ernst at cron-it.de
Tue May 29 11:51:29 CEST 2012
François Suter schrieb am 29.05.2012 11:30:
> I just noticed that t3lib_utility_Mail::mail() does not use SwiftMailer,
> but calls PHP's mail() instead. Is that intentional? If yes, what is the
Not true. :) It does use SwiftMailer. See explanation below...
> I find this rather embarrassing as I was testing something in
> workspaces/version and was counting on intercepting the mails by
> changing my transport to "mbox", which proved to be impossible in this
> case because the stage change notification relies on
> t3lib_div::plainMailEncoded() which itself calls
> Is there any reason not to use the SwiftMailer API in this case? And in
> general any reason not to use it throughout the whole Core?
t3lib_utility_Mail::mail was meant to be a "wrapper" for PHP's mail()
routine. As such, it doesn't provide a very usable API, as you can throw
in any kind of (non-RFC) parameters into it. For example your own
headers, use your own encoding (in headers and body) etc. It is very
difficult (if not impossible) to transform this "garbage input" into
something that is RFC conformant.
Nevertheless Jigal made it possible, and our SwiftMail API "plugins"
into the t3lib_utility_Mail::mail by implementing the hook
"substituteMailDelivery" (see t3lib_mail_SwiftMailerAdapter).
In 4.5 and 4.6 this API substitution was optional and configurable, see:
The reason is that many "old school" extensions will break if you do
this substititution (extensions which hand-craft non RFC-conformant
mails by hand), in form of Exceptions from the SwiftMail engine. So in
those situations you had to "disable" this "substituteOldMailAPI" which
then makes t3lib_utility_Mail::mail work as before (by just calling
In 4.7 this option was removed, thus every call to
t3lib_utility_Mail::mail will go through SwiftMail.
Now to the future: t3lib_utility_Mail::mail is an old API which should
not be used anymore. A shame is that we didn't deprecated it "back
then", and encourage more people to simply use the modern t3lib_mail
API. One drawback was that you cannot simply send an email with "one
like of code" with t3lib_mail. You need to create an object, set
attributes, etc. So one potential solution to this would be to create
some helper methods which are very easy to use and call t3lib_mail
See my reply in thread "t3lib_utility_mail vs t3lib_mail?" from Tolleiv
(4.1.2012, typo3.core) for my further thoughts about it.
More information about the TYPO3-team-core