[Mailman-Developers] suggested improvement for Mailman's bounce processing

[Brad Knowles]

At 10:55 AM +0100 2006-08-08, Ian Eiloart wrote:

>>  The problem is determining, in a programmatic and systematic way,
>>  what really is a content-related bounce and what might mistakenly
>>  appear to be a content-related bounce, and the converse.
>
>  No, that isn't the problem. The RFC says how to do this, and we should
>  trust the RFC. If people have broken servers then actually there's
>  nothing that can go wrong which isn't already going wrong.

And if Yahoo jumps off a bridge because they think the RFC tells them 
to do that, what should we do?  And what if AOL, pobox.com, 
hotmail.com, and all the other big providers make the same mistake?

When it comes to parsing the actual reasons behind a message 
bouncing, the RFC is not sufficient.  Indeed, I'm not convinced that 
it's even necessary.  And you'd have to be specific which RFC you're 
talking about, because some of them are mutually incompatible.

Trust me, this is a more complex subject than you think it is.

And just blindly applying what you think is the right solution is 
likely to cause a lot more pain for you and for everyone else, and 
not necessarily for any real good purpose when everything is said and 
done.

>  I can't see that data is required.

Then go ahead and make the change, and then tell us how it works out for you.

>                                      There are two categories of error, and
>  the consequences are neutral in both cases:
>
>  1. A message is labelled as a content bounce when it's really a recipient
>   bounce.

Or some other kind of bounce.

>    The consequence is that the recipient stays subscribed. This isn't a
>  real problem. The worst that happens is a bit of extra traffic, or that
>  the admin reverts to the old behaviour.

This can be a very real problem for admins that are running larger 
sites, and already handling large amounts of traffic.  If the admin 
is forced to disable some new feature in order to restore his site to 
a reasonably well working state, then he's not likely to make that 
upgrade.

>  2. The message is labelled as a recipient bounce when it's really a
>  content bounce.

Or some other kind of bounce.

>    This is the status quo. People may already be incorrectly unsubscribed.
>  This is a real problem when it occurs. It can happen because a server
>  refuses messages with illegal (RFC non-compliant) headers, as well as when
>  the content is offensive.

Or when the server looks up your IP address and finds it on a black 
list, or thinks it finds it on a blacklist which no longer exists, or 
any number of other problems.

We can't fix the entire Internet, and when people have misconfigured 
their servers to generate inappropriate types of bounces, there's not 
much we can do to help them.


In my experience, any kind of guess that we might be able to make 
programmatically is usually wrong for a statistically significant 
subset of the population.

Moreover, the potential damage from false positives or false 
negatives is usually worse for the collective whole than simply not 
trying to guess one way or the other, and to just give people enough 
lattitude that it shouldn't matter.


But you've got the opportunity here to generate real-world data on 
how this process works, and to put the whole issue to rest.  Please 
let us know how it works out for you.

-- 
Brad Knowles, <brad at 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, 1755

  Founding Individual Sponsor of LOPSA.  See <http://www.lopsa.org/>.