On 11/06/14 14:49, I wrote:
In particular, there is a mail library called SwiftMailer which provides bounce detection, among other things. Bounce detection would be a nice thing to have.
Sorry, it seems I was misled on this. SwiftMailer does not have any special handling for bounces, judging by the code review I have done just now and
http://pookey.co.uk/wordpress/archives/183-using-verp-with-swiftmailer-symfony-and-exim
All it has is a setReturnPath() method, and of course we have equivalent code in UserMailer.php already:
$headers['Return-Path'] = $from->address;
With VERP this would become:
$headers['Return-Path'] = $this->makeReturnPath( $from );
or some such. With SwiftMailer, you could instead have:
$message->setReturnPath( $this->makeReturnPath( $from ) );
...with identical implementation of makeReturnPath(). SwiftMailer does not give you any help in receiving bounces. It has no MIME parsers or clients for POP, IMAP, MTA pipes, etc.
On [[Talk:VERP]], Tyler suggested writing a SwiftMailer plugin to "implement VERP", by which he apparently means a plugin which would serialize the relevant parameters and calculate an HMAC, and then set the return path.
Presumably this would look like:
$verp = new Swift_Plugins_VerpPlugin( array( 'wiki' => wfWikiId(), 'ua' => 'UserMailer', 'time' => wfTimestampNow() ), $secretKey ) ); $mailer->registerPlugin( $verp ); $mailer->send( $message );
With Swift_Plugins_VerpPlugin being along the lines of:
class Swift_Plugins_VerpPlugin { function __construct( $context ) { $this->context = $context; }
function beforeSendPerformed( $evt ) { $message = $evt->getMessage(); $message->setReturnPath( $this->makeReturnPath( $message->getReturnPath() ) ); } ... }
...with makeReturnPath() being the serialization code, equivalent to my suggestion of UserMailer::makeReturnPath() above.
On [[Talk:VERP]], Jeff Green was fairly skeptical about the value of doing it this way, and I guess I am too. You have to wonder where the boundary is between abstraction and needless complexity. And where do you put the receive code? Surely the return path parser and the return path printer should be maintained together. SwiftMailer is basically just an SMTP client. I would think that a bounce processing feature as a whole would be an elegant thing to put a module boundary around, rather than having half of it implemented as an SMTP client plugin and the other half implemented as a MediaWiki-specific CLI interface for an MTA pipe.
In other news, I found a serious security vulnerability in SwiftMailer and have reported it upstream.
-- Tim Starling