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