thoughts on bounce processing
Per Barry's request, I thought I'd describe some of the issues our sites has encountered with Mailman lists and bounce messages.
At our site, we currently 15,775 subscribers (8,296 unique) across 549 lists. While a few of the lists are huge (hundreds or thousands of subscribers), the median list size is only 4 subscribers.
The primary issue we are encountering is that the vast majority of our lists (even the ones with hundreds of subscribers) are announcement-type lists, not discussion-type lists. The list owners are using the lists to reach coworkers, specific customers, course attendees, etc. The list admins know exactly which addresses are on their lists, because they've added them all themselves.
Situations like this happen all the time:
1. A VIP asks an administrative assistant to send out a message
to a group of people: team members, specific customers, etc.
2. The AA sends the message to the appropriate Mailman list.
Unbeknown to the AA, one of the addresses bounces.
3. The person whose address bounced doesn't get the message, and
(e.g.) misses an important meeting, fails to provide some
important information, etc.
4. The VIP comes down hard on the AA for failing to notify
everyone.
5. The AA comes to us full a fire and brimstone, complaining the
Mailman doesn't permit people to perform necessary business
functions.The issue is that people in this situation *want* to see the individual bounces, and they want to see them *immediately*, because the bounces contain important information that they might need to act upon. The closest they can get to that right now is to configure the list so that a single bounce immediately removes the subscriber from the list. But this isn't always the correct thing to do. (For example, lots of people seem to have broken vacation programs that respond to *everything*, and they continually get unsubscribed from lists.)
The more I think about this, the more I think that silently discarding bounces is an error. While some bounces are irrelevant (e.g. vacation messages), in the majority of cases, bounces are information that some entity should act upon. There should be two (and only two) options:
1. Mailman processes all bounces.
2. All bounces are forwarded to the list administrator(s).I've attached my first attempt at implementing this behavior. (I say "first attempt" because I'd really like to get both the listname and the address that bounced into the Subject header, but to do that requires more complicated logic than what I've implemented so far.)
If list admins *really* want to (effectively) discard all bounces, they can e.g. set bounce_info_stale_after to 1 and then set bounce_score_threshold to something impossibly high (e.g. 500,000).
Thoughts?
James
On Thu, May 11, 2006 at 01:24:36PM -0400, James Ralston wrote:
<snip> > The primary issue we are encountering is that the vast majority of our > lists (even the ones with hundreds of subscribers) are > announcement-type lists, not discussion-type lists. The list owners > are using the lists to reach coworkers, specific customers, course > attendees, etc. The list admins know exactly which addresses are on > their lists, because they've added them all themselves. > <snip> > > The issue is that people in this situation *want* to see the > individual bounces, and they want to see them *immediately*, because > the bounces contain important information that they might need to act > upon. <snip> > > The more I think about this, the more I think that silently discarding > bounces is an error. While some bounces are irrelevant (e.g. vacation > messages), in the majority of cases, bounces are information that some > entity should act upon. There should be two (and only two) options: > > 1. Mailman processes all bounces. > 2. All bounces are forwarded to the list administrator(s). <snip> > > Thoughts?
The way Mailman is being used at your site is very similar to what we at the Tilburg University are doing (and, I bets, _lots_ of other big sites). What you're proposing seems to be what we need (we've been lucky thus far: I haven't had a raging VIP at my desk (yet!)) . Very likely, there are more interested sites.
Thanks, Bye,
Joost
-- Joost van Baal http://abramowitz.uvt.nl/ Tilburg University j.e.vanbaal@uvt.nl The Netherlands
At 1:24 PM -0400 2006-05-11, James Ralston wrote:
The more I think about this, the more I think that silently discarding bounces is an error.
Mailman doesn't silently discard bounces. It keeps a counter, and for each day that a bounce is received, that counter is incremented. Multiple additional bounces on a single day do not cause the counter to be incremented, but they are still examined.
While some bounces are irrelevant (e.g. vacationmessages), in the majority of cases, bounces are information that some entity should act upon. There should be two (and only two) options:
1. Mailman processes all bounces. 2. All bounces are forwarded to the list administrator(s).
In your example above, that would only be appropriate if the AA is the list administrator. I think a better method would be to have all bounces sent to the poster, regardless of who that poster is. If it's an announcement-only list, then presumably you have a restricted set of people who can post to that list, and any one of them should be able to handle bounces sent directly back to them.
This would imply that the envelope sender is left unmodified by Mailman, and that could potentially cause problems with things like SPF or DKIM, which the sender would need to be aware of.
And hopefully you wouldn't use this kind of mechanism on an announcement-only list with thousands of recipients.
That said, I can see that this would be a reasonable enhancement to request.
If list admins *really* want to (effectively) discard all bounces, they can e.g. set bounce_info_stale_after to 1 and then set bounce_score_threshold to something impossibly high (e.g. 500,000).
Keep in mind that I've seen mail loops quickly spin into the thousands in a matter of minutes, especially when the messages are passing through systems that scrub what they consider to be non-useful headers like "Received:".
I don't know that there's much of anything you could do about such loops. I think the only thing I'd say here is that I'd tend to be a little more conservative in terms of what I'd call "impossibly high". ;)
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755LOPSA member since December 2005. See http://www.lopsa.org/.
On 2006-05-11 at 14:34-05 Brad Knowles brad@stop.mail-abuse.org wrote:
At 1:24 PM -0400 2006-05-11, James Ralston wrote:
The more I think about this, the more I think that silently discarding bounces is an error.
Mailman doesn't silently discard bounces.
It does if bounce_processing is set to "no". That's my point: turning off bounce processing should mean "forward the bounces to the list administrator(s)", not "discard bounces".
There should be two (and only two) options:
- Mailman processes all bounces.
- All bounces are forwarded to the list administrator(s).
In your example above, that would only be appropriate if the AA is the list administrator. I think a better method would be to have all bounces sent to the poster, regardless of who that poster is. If it's an announcement-only list, then presumably you have a restricted set of people who can post to that list, and any one of them should be able to handle bounces sent directly back to them.
An intriguing thought. But...
This would imply that the envelope sender is left unmodified by Mailman, and that could potentially cause problems with things like SPF or DKIM, which the sender would need to be aware of.
If the envelope sender is unmodified, then Mailman can't use VERP, which means that the likelihood that the bounce will contain useful information (such as, which address actually bounced) is reduced. :(
I suppose Mailman could stuff the original envelope sender header into another header (e.g., "X-Mailman-Original-Env-Sender") and then pull it back out when processing a bounce, but that smells rather hackish to me.
Perhaps VERP could be enhanced to encode both the original envelope sender and the recipient?
If list admins *really* want to (effectively) discard all bounces, they can e.g. set bounce_info_stale_after to 1 and then set bounce_score_threshold to something impossibly high (e.g. 500,000).
Keep in mind that I've seen mail loops quickly spin into the thousands in a matter of minutes, especially when the messages are passing through systems that scrub what they consider to be non-useful headers like "Received:".
I don't know that there's much of anything you could do about such loops. I think the only thing I'd say here is that I'd tend to be a little more conservative in terms of what I'd call "impossibly high". ;)
Point taken.
But situations like this are what the "emergency moderation" setting is for, yes?
James
At 4:50 PM -0400 2006-05-11, James Ralston wrote:
Mailman doesn't silently discard bounces.
It does if bounce_processing is set to "no".
Ahh. Sorry, I had missed that part of the issue.That's my point: turningoff bounce processing should mean "forward the bounces to the list administrator(s)", not "discard bounces".
s/list administrator(s)/appropriate place/
In some cases, the list moderator(s) might be the appropriate place, in others the original poster will be the appropriate place. I think there's some room here for further discussion.
This would imply that the envelope sender is left unmodified by Mailman, and that could potentially cause problems with things like SPF or DKIM, which the sender would need to be aware of.
If the envelope sender is unmodified, then Mailman can't use VERP, which means that the likelihood that the bounce will contain useful information (such as, which address actually bounced) is reduced. :(
Not really. VERP could be used, but then that would require that the MTA of the poster would also understand that format.
I suppose Mailman could stuff the original envelope sender header into another header (e.g., "X-Mailman-Original-Env-Sender") and then pull it back out when processing a bounce, but that smells rather hackish to me.
That sort of thing may be the only alternative, if you want to have the bounces sent back to the original poster.
Sending things to the list moderator(s) or administrator(s) would be simpler, since you wouldn't have to worry what the original envelope sender address was.
But that would only help you if the original poster was also one of the list moderator(s) or administrator(s).
Perhaps VERP could be enhanced to encode both the original envelope sender and the recipient?
The problem is that subscribers might have their own plus-style addressing, on top of which we're trying to add VERP, and now you're trying to encode both the envelope sender and envelope recipient in the VERP.
That might be theoretically possible, but I think it's going to take a lot more thought and design work to see if that can be done. I suspect it would be a lot easier to do some of the other sorts of things we're talking about.
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755LOPSA member since December 2005. See http://www.lopsa.org/.
On Thu, May 11, 2006 at 04:50:14PM -0400, James Ralston wrote:
I suppose Mailman could stuff the original envelope sender header into another header (e.g., "X-Mailman-Original-Env-Sender") and then pull it back out when processing a bounce, but that smells rather hackish to me.
Perhaps VERP could be enhanced to encode both the original envelope sender and the recipient?
I suppose this is more for MM3, but if the origina message IDs are preserved in bounce messages perhaps MM could keep a database of all messages that went through it including IDs. When a bounce comes back it could pull the original sender from that database and notify them, the list administrator, someone's next of kin, or whoever depending on what had been configured.
Just thinking aloud... :o)
Regards, Msquared...
participants (4)
-
Brad Knowles -
James Ralston -
Joost van Baal -
Msquared