Christopher Adams wrote:

One concern - Charles mentioned how 'expensive' it was to use VERP with Postfix. I am wondering what kind of hit on the responsiveness of my Mailman server will be. I have over 500 lists and 250,000 subscribers. If VERP being used for Mailman causes more mail activity, could this result in slowness of list message delivery?

The short answer is yes.

But let's be clear on what we're talking about.

First, we are not talking about VERP_CONFIRMATIONS = Yes. All this does is remove the confirm token from the Subject: and put it in the From: address and replace the Subject: with a more user friendly one. It has no impact on performance because these messages are sent one recipient at a time anyway.

What we are talking about is Variable Envelope Return Paths. I.e., each recipient (e.g. recip@user.example.com) of a message (sent from the listname@list.example.com list) gets a message sent with an envelope from

listname-bounces+recip=user.example.com@list.example.com

Then when a bounce is returned to that address, it is delivered to listname-bounces@list.example.com and Mailman knows that the user that bounced is recip@user.example.com without having to parse the actual bounce message and regardless of where the message might have been forwarded/aliased in between.

If mailman does this VERPing (e.g. by setting VERP_DELIVERY_INTERVAL = 1), then Mailman is required to send to each recipient in a separate SMTP transaction instead of a few transactions with a few hundred recipients each, because each recipient has a unique envelope from. List personalization also requires this because each recipient gets a different message. That's why Mailman has a setting for VERP_PERSONALIZED_DELIVERIES since if the deliveries are personalized to begin with, Mailman's VERPing doesn't cost extra.

The alternative is to have the MTA do the VERPing. In this case delivery from Mailman to the MTA proceeds just as in the non-VERP case, but delivery from the MTA to the recipient domains might require more work. I.e., in the non-verp case, Mailman gives a message with 500 recipient addresses to the MTA in one SMTP transaction. If 25 of these are aol.com addresses, the MTA may deliver the message to AOL in one transaction with 25 recipients, but if the MTA is VERPing, it is required to deliver to AOL in 25 separate transactions. So the impact is greater than for non-VERP, but significantly less than if Mailman does the VERPing. The problem is that unless the MTA can be configured to VERP every outgoing message (which you may not want to do even if you can), Mailman has to be patched to request that the MTA does VERP for 'this' message.

As a point of reference however, there are lots of lists on python.org and some are quite busy (e.g. Python-list@python.org) and they are personalized and it seems to work OK. Brad has posted on this in the past <http://mail.python.org/pipermail/mailman-users/2007-September/058231.html>.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 11/27/07, Christopher Adams wrote:

One concern - Charles mentioned how 'expensive' it was to use VERP with Postfix. I am wondering what kind of hit on the responsiveness of my Mailman server will be.

There has been some research on this topic, which is summarized at <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.012.htp>.

                         I have over 500 lists and 250,000

subscribers.

That would be one of the larger mailing lists known to be running Mailman, see <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.015.htp>.

           If VERP being used for Mailman causes more mail activity,

could this result in slowness of list message delivery?

Well, it all comes down to how much activity your lists have. A list that has hundreds of thousands of subscribers but which only gets one post per month is not necessarily going to see the same sets of performance problems as a site that has a smaller number of lists with a smaller number of recipients, but where the lists are very active.

For that second URL shown above, contrast the profiles of HostMySite.com and panic.com as compared to lists.apple.com and FreeBSD.org.

Going back to that first URL shown above, I think the most critical summary paragraphs are these:

The network penalty between SMTP_MAX = 1 (effectively VERP) and any kind of batching (SMTP > 1) is roughly 50%. To get VERP or customized footers or customized anything, you double your network bandwidth.

There is very little advantage to setting SMTP_MAX > 5, UNLESS your subscriber base is heavily stratified onto very few sites. If you have really large groups of subscribers on AOL or Hotmail, it can help cut network bandwidth, but at best, it seems to be about a 10% improvement.

Keep in mind that this is for the test set described, but we believe that this is a reasonably accurate description of many Mailman mailing list servers & services.

-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>

Christopher Adams wrote:

One concern - Charles mentioned how 'expensive' it was to use VERP with Postfix. I am wondering what kind of hit on the responsiveness of my Mailman server will be. I have over 500 lists and 250,000 subscribers. If VERP being used for Mailman causes more mail activity, could this result in slowness of list message delivery?

The short answer is yes.

But let's be clear on what we're talking about.

First, we are not talking about VERP_CONFIRMATIONS = Yes. All this does is remove the confirm token from the Subject: and put it in the From: address and replace the Subject: with a more user friendly one. It has no impact on performance because these messages are sent one recipient at a time anyway.

What we are talking about is Variable Envelope Return Paths. I.e., each recipient (e.g. recip@user.example.com) of a message (sent from the listname@list.example.com list) gets a message sent with an envelope from

listname-bounces+recip=user.example.com@list.example.com

Then when a bounce is returned to that address, it is delivered to listname-bounces@list.example.com and Mailman knows that the user that bounced is recip@user.example.com without having to parse the actual bounce message and regardless of where the message might have been forwarded/aliased in between.

If mailman does this VERPing (e.g. by setting VERP_DELIVERY_INTERVAL = 1), then Mailman is required to send to each recipient in a separate SMTP transaction instead of a few transactions with a few hundred recipients each, because each recipient has a unique envelope from. List personalization also requires this because each recipient gets a different message. That's why Mailman has a setting for VERP_PERSONALIZED_DELIVERIES since if the deliveries are personalized to begin with, Mailman's VERPing doesn't cost extra.

The alternative is to have the MTA do the VERPing. In this case delivery from Mailman to the MTA proceeds just as in the non-VERP case, but delivery from the MTA to the recipient domains might require more work. I.e., in the non-verp case, Mailman gives a message with 500 recipient addresses to the MTA in one SMTP transaction. If 25 of these are aol.com addresses, the MTA may deliver the message to AOL in one transaction with 25 recipients, but if the MTA is VERPing, it is required to deliver to AOL in 25 separate transactions. So the impact is greater than for non-VERP, but significantly less than if Mailman does the VERPing. The problem is that unless the MTA can be configured to VERP every outgoing message (which you may not want to do even if you can), Mailman has to be patched to request that the MTA does VERP for 'this' message.

As a point of reference however, there are lots of lists on python.org and some are quite busy (e.g. Python-list@python.org) and they are personalized and it seems to work OK. Brad has posted on this in the past <http://mail.python.org/pipermail/mailman-users/2007-September/058231.html>.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 11/27/07, Christopher Adams wrote:

One concern - Charles mentioned how 'expensive' it was to use VERP with Postfix. I am wondering what kind of hit on the responsiveness of my Mailman server will be.

There has been some research on this topic, which is summarized at <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.012.htp>.

                         I have over 500 lists and 250,000

subscribers.

That would be one of the larger mailing lists known to be running Mailman, see <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.015.htp>.

           If VERP being used for Mailman causes more mail activity,

could this result in slowness of list message delivery?

Well, it all comes down to how much activity your lists have. A list that has hundreds of thousands of subscribers but which only gets one post per month is not necessarily going to see the same sets of performance problems as a site that has a smaller number of lists with a smaller number of recipients, but where the lists are very active.

For that second URL shown above, contrast the profiles of HostMySite.com and panic.com as compared to lists.apple.com and FreeBSD.org.

Going back to that first URL shown above, I think the most critical summary paragraphs are these:

The network penalty between SMTP_MAX = 1 (effectively VERP) and any kind of batching (SMTP > 1) is roughly 50%. To get VERP or customized footers or customized anything, you double your network bandwidth.

There is very little advantage to setting SMTP_MAX > 5, UNLESS your subscriber base is heavily stratified onto very few sites. If you have really large groups of subscribers on AOL or Hotmail, it can help cut network bandwidth, but at best, it seems to be about a 10% improvement.

Keep in mind that this is for the test set described, but we believe that this is a reasonably accurate description of many Mailman mailing list servers & services.

-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>