At 3:08 PM -0400 2006-08-07, James Ralston wrote:
Perhaps, but we cannot solve this problem, and there's a fine line between working around stupidity and coddling it.
Right, but if we can't fix the problem of the multitude of broken MTAs out there, and the fact that most of them probably don't assign the appropriate extended response codes in accordance with the RFCs, then the likelihood is that we are going to be lead to make the wrong guesses based on the response we get.
I think the question is how damaging are those wrong guesses, and as compared to not making any attempt to guess one way or the other and just treat all bounces as the same?
Without any further detailed information, my gut feeling is that we're better off not trying to guess what the real reason was for a given bounce, but to just treat them all the same and to give enough lattitude that people don't get unsubscribed with just a single bounce (or whatever).
What further data do you wish to see? I think I've documented the problem well enough. There's no way we know many horribly broken sites are out there.
Save a copy of each and every bounce you get over an extended period of time (this may require modifications to the source code), and then try to categorize them by the easy-to-parse numeric response code versus the harder-to-parse description, and actually find out how the cookie crumbles.
Describing the one particular type of sub-problem that you've run into doesn't really help us in this situation, not when you're talking about changing the behaviour of an entire subsystem in order to accommodate your one specific issue.
Instead, you need to go on a quest to obtain large amounts of data that demonstrate how easy (or hard) it is to determine the real reason why some message bounced and then figure out how you can take that information and modify the source code to suit.
Right: the only risk is that bounces coming from a subscriber at a broken site might be ignored, because they look like they're being generated based on the content of certain messages.
I'm not convinced that's the only risk, and I'm not convinced that the potential consequences are that minor. But if you can provide sufficient evidence to show that you are correct, at least for the users on your site, I'm willing to be convinced.
IMHO, this risk is negligible. If the operators of the broken site in question get annoyed that Mailman keeps trying to send messages to a non-existent address, they should fix their broken site.
Well, if the windmill turns out to be Microsoft, you might want to seriously think about whether or not you really want to continue trying to tilt at that thing.
You might want to look into how big this problem could potentially be, before you decide to just casually blow off any possible consequences.
-- 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, 1755Founding Individual Sponsor of LOPSA. See <http://www.lopsa.org/>.