[TYPO3-core] RFC #16610: Provide a SwiftMailer transport that only saves send mails to files

Ernesto Baschny [cron IT] ernst at cron-it.de
Wed Dec 1 21:23:19 CET 2010


Jeff Segars schrieb am 30.11.2010 21:21:

>> This is a SVN patch request.
>>
>> Type: Feature
>>
>> BT reference: http://bugs.typo3.org/view.php?id=16610
>>
>> Branches: trunk
>>
>> Problem:
>> We introduced the SwiftMailer interface in t3lib_mail in 4.5 alpha2. So
>> we can now generate RFC conforming mails and have a powerful mail engine
>> available which also supports different transport mechanisms (like
>> mail(), sendmail and direct SMTP).
>>
>> To ease debugging mail sending in a TYPO3 installation, it might be
>> useful for a complete installation not really *send* mails, but just
>> save them to a file.
>>
>> This RFC provides this feature, allowing the admin to configure the new
>> transport "mbox", which saves all mails to a mbox-conformant file
>> (simple text file, see RFC 4155). This file can be viewed with a regular
>> text editor or a mail client which can open a "mbox" file.
>>
>> Together with Jigal's RFC #16591 which hooks into all other mail() usage
>> we are able to log every outgoing mail to a file!
>>
>>
>> How to test:
>> Set transport to "mbox" in the install tool and configure the desired
>> output file. Install Jigal's patch (manually fix the conflict in the
>> core_autoloader file..) or use the attached patch which adds t3lib_mail
>> support to the scheduler test task and just let TYPO3 send some mails!
>>
>>
>> Additional info:
>> This feature is a follow-up the the new mailing API and will be included
>> according to the rules for "new features" in this phase (see
>> http://forge.typo3.org/projects/typo3v45-projects/wiki/Feature_Freeze,
>> where "t3lib_mail" is listed as potential candidates for follow-ups).

> Hey Ernesto,
> Nice feature! +1 on reading and testing with 2 small comments
> 
> * Currently transport_mbox_file must be an absolute path. It would be
> nice to either support a relative path or mention that its absolute
> since it varies throughout the Install Tool.

I followed the current example of "sysLog" 'file' setting, which also
requires a full path. I agree that a relative path is more flexible (to
be able to share the setting across multiple installations).

I tried to make a "relative" path using the safe methods we have in
t3lib_div, but was unable to:

For example I have my PATH_site /home/www/htdocs/ and I set:
$TYPO3_CONF_VARS['BE']['lockRootPath'] = "/home/www/"

And then wanting my mbox file in "../logs/mbox" for example, I would
expect it to be placed in "/home/www/logs/mbox". But to make it "safe" I
used t3lib_div::getFileAbsFileName(), but this does not allow a "../" in
the path *at all* (even if the result would remain in the lockRootPath).

So I have no idea on how to get a relative and safe path outside the
rootPath, because it makes no sense to store this kind of file inside
the docRoot!

So I keep it as "absolute" for now, and maybe we find some method to
make the relative paths "safe" later on (and maybe also apply that to
sysLog and other settings).

It might make sense to have a global ['SYS']['privateDataFolder'] in
future which can reside *outside* the DocRoot and which we can just
refer to with "PRIVATE:filename" (analog to "EXT:..." syntax) and
t3lib_div::getFileAbsFileName() would take care of it.

> * In getReversePath() there's a little CGL cleanup needed on the elseif
> conditions.

True! That method is a copy of
typo3/contrib/swiftmailer/classes/Swift/Transport/MailTransport.php and
I forgot to adapt to our CGL.

> Otherwise, all looks good.  Thanks!

Cool thanks. One more +1 and we are ready to go. any volunteer? ;)

Cheers,
Ernesto
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 16610-v2.patch
URL: <http://lists.typo3.org/pipermail/typo3-team-core/attachments/20101201/d13ff047/attachment.asc>


More information about the TYPO3-team-core mailing list