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:
- A message is labelled as a content bounce when it's really a recipient
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.
- The message is labelled as a recipient bounce when it's really a
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.