Talk:VERP

Previous page history was archived for backup purposes at Talk:VERP/LQT Archive 1 on 2015-06-25.

Not that we care about DreamHost, but I found this curious: http://wiki.dreamhost.com/MediaWiki#Domain_spoofing

Hello, please create a wiki-specific category or tag on http://tttwrites.in/ and then ask addition of it to m:Planet Wikimedia.

Done here at http://tttwrites.wordpress.com/category/wikimedia/. I will request in Planet Wikimedia

Hi Tyler,

I was going through your recommendations on replacing PHP mailer with Swift Mailer. I was working with Jeff and Legoktm on
implementing VERP feature to handle e-mail bounces. Nemo told me about adding the porting too in my proposal, as its worth it .
Can you comment on the proposal about the feasibility of implementing VERP in swift mailer than on the PHP mailer ? Propsal link:- https://www.mediawiki.org/wiki/VERP

Hey,

Implementing VERP using SwiftMailer should be pretty trivial. All you have to do is transform the recipient email and add it to the Return-Path header. I'd actually recommend implementing VERP as a plugin to SwiftMailer (since SwiftMailer is extensible) if you plan on doing that.

Hi, I will talk with my mentors on that. I am confused when the porting needs to be done. If VERP is to be implemented as a plugin fro SwiftMailer, probably we need to port first.

Tyler could you elaborate on the plugin suggestion? Why a plugin rather than simply setting Return-Path when calling the mailer?

I mean, you can structure it any way you see fit. In this case VERP is pretty simple, but usually it's more modular to make it a plugin. Rather than calculating the Return-Path header value in controller code, you'd have the plugin calculate it automatically based on the recipient.

I think we intend to encode more than just the recipient address in the VERP hash--the current plan is to use HMAC with a secret key to encode recipient address, origination time, and list name in the hash. So the plugin would need access to a bunch of contextual data to generate the hash.

In that case it makes even more sense to do it as a plugin. The plugin would have access to whatever context it needs, and whatever code is sending the mail does not need to worry about the HMAC calculation. In other words, you want a separation of concerns so that anybody who is using SwiftMailer only need to worry about what is actually being put in the message.