Re: [Mailman-Developers] Maybe you guys can help me
On Tue, 4 May 2004 07:03:26 -0400 Paul Tomblin <ptomblin@xcski.com> wrote:
I do have some control over the MTA. But it does seem a little ridiculous to filter out warnings (but not errors) just because mailman insists on treating warnings as errors.
Reliably distinguishing is non-trivial.
-- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
--On Tuesday, May 04, 2004 10:25 AM -0400 J C Lawrence <claw@kanga.nu> wrote:
On Tue, 4 May 2004 07:03:26 -0400 Paul Tomblin <ptomblin@xcski.com> wrote:
I do have some control over the MTA. But it does seem a little ridiculous to filter out warnings (but not errors) just because mailman insists on treating warnings as errors.
Reliably distinguishing is non-trivial.
Incorrect. Parsing RFC-standard DSNs is trivial. I wrote the code to do it back in the old days when I ran the firewalls mailing list.
-- Carson
At 11:40 AM -0400 2004/05/04, Carson Gaspar quoted JC Lawrence:
Reliably distinguishing is non-trivial.
Incorrect. Parsing RFC-standard DSNs is trivial. I wrote the code to do it back in the old days when I ran the firewalls mailing list.
I think JC was talking about the broader subject, more than just the standard DSNs.
I agree with you that we could do a better job of parsing and handling the standard DSNs, but I agree with JC that this is a very tough task to do beyond the standard DSNs.
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
SAGE member since 1995. See <http://www.sage.org/> for more info.
On Tue, 2004-05-04 at 11:56, Brad Knowles wrote:
I think JC was talking about the broader subject, more than just the standard DSNs.
I agree with you that we could do a better job of parsing and handling the standard DSNs, but I agree with JC that this is a very tough task to do beyond the standard DSNs.
Mailman /should/ be able to parse RFC 3464 DSNs accurately, at the very least to tell whether the notification indicates a permanent failure or not. If it's not working right, it's a bug.
All the 'magical' bounce detection stuff in the other Mailman/Bouncers modules is a losing battle, and I don't have much motivation to keep up with the arms race. DSN and VERP should be all we need.
-Barry
And how many "RFC-Standard" DSNs are out there, compared to non-standard? He's right, it is not the least bit trivial.
Bob
Carson Gaspar wrote:
--On Tuesday, May 04, 2004 10:25 AM -0400 J C Lawrence <claw@kanga.nu> wrote:
On Tue, 4 May 2004 07:03:26 -0400 Paul Tomblin <ptomblin@xcski.com> wrote:
I do have some control over the MTA. But it does seem a little ridiculous to filter out warnings (but not errors) just because mailman insists on treating warnings as errors.
Reliably distinguishing is non-trivial.
Incorrect. Parsing RFC-standard DSNs is trivial. I wrote the code to do it back in the old days when I ran the firewalls mailing list.
Quoting Bob Puff@NLE (bob@nleaudio.com):
And how many "RFC-Standard" DSNs are out there, compared to non-standard?
He's right, it is not the least bit trivial.
The point is that Mailman already has code to parse dozens of different bounce messages. I don't see why everybody is getting so hinky about adding one more.
-- Paul Tomblin <ptomblin@xcski.com> http://xcski.com/blogs/pt/ "The surreality of the universe tends towards a maximum" -- Skud's Law "Never formulate a law or axiom that you're not prepared to live with the consequences of." -- Skud's Meta-Law
...Because it's not just one more. I re-wrote the bounce handling for my own 2.0.x boxes, and spent endless hours trying to keep up with all the difference bounce messages that weren't caught. I ended up giving up. If their ISP is broken enough that it generates bounce messages, then their unsubscription problem isn't mine.
What will happen is that your test for "soft" bounces is going to register some "hard" bounces incorrectly, and then its downhill from there.
I haven't looked at the latest handlers, but my code says something like: if the person hasn't bounced in two days (of messages each day), then reset their counter. So if they constantly generate these messages, there is a very real problem with that ISP.
Bob
---------- Original Message ----------- From: Paul Tomblin <ptomblin@xcski.com> To: mailman-developers@python.org Sent: Tue, 4 May 2004 12:08:06 -0400 Subject: Re: [Mailman-Developers] Maybe you guys can help me
Quoting Bob Puff@NLE (bob@nleaudio.com):
And how many "RFC-Standard" DSNs are out there, compared to non- standard?
He's right, it is not the least bit trivial.The point is that Mailman already has code to parse dozens of different bounce messages. I don't see why everybody is getting so hinky about adding one more.
-- Paul Tomblin <ptomblin@xcski.com> http://xcski.com/blogs/pt/ "The surreality of the universe tends towards a maximum" -- Skud's Law "Never formulate a law or axiom that you're not prepared to live with the consequences of." -- Skud's Meta-Law
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob% 40nleaudio.com ------- End of Original Message -------
Quoting Bob Puff@NLE (bob@nleaudio.com):
I haven't looked at the latest handlers, but my code says something like: if the person hasn't bounced in two days (of messages each day), then reset their counter. So if they constantly generate these messages, there is a very real problem with that ISP.
The problem seems to be that they hold up email for 4 or 5 hours a day for several days in a row. Hundreds of messages a day get through correctly, but if one of them is held up for four hours each day for the designated number of days, she gets bounced off.
Yeah, it's a problem with her ISP. That's not my problem. My problem is that Mailman has dozens if not hundreds of individual specialized bounce handlers, I asked for help with modifying one of them, and everybody treats me like I'm asking for how to draw a moustache on the Mona Lisa.
The code is already a nest of special cases. It won't hurt the pristine nature of the perfect code to add a small check and NOT mishandle one thing that is erroneously treated as a bounce. Especially since it appears that somebody already added something to the API to allow warnings to be silently ignored.
I figured somebody who knew the code could tell me what and where to change it in less time than it would take to argue about it, but I guess I was wrong. Sorry I pissed on your wheaties, guys. I guess I'll buy a Python book and do it myself.
-- Paul Tomblin <ptomblin@xcski.com> http://xcski.com/blogs/pt/ SCSI is *NOT* magic. There are *fundamental technical reasons* why it is necessary to sacrifice a young goat to your SCSI chain now and then.
On Tue, 2004-05-04 at 13:42, Paul Tomblin wrote:
The code is already a nest of special cases. It won't hurt the pristine nature of the perfect code to add a small check and NOT mishandle one thing that is erroneously treated as a bounce. Especially since it appears that somebody already added something to the API to allow warnings to be silently ignored.
Actually, it may, so if you decide to code it up (and it /definitely/ ain't gonna happen if you don't), you need to be careful. If your change catches something or reports a false-positive or false-negative, it could cause other bounce processors to miss the message.
I wish the bounce processors had a better test suite, but you can (and should) add your additions to tests/test_bounces.py and make sure everything there still passes.
-Barry
handlers, I asked for help with modifying one of them, and everybody treats me like I'm asking for how to draw a moustache on the Mona Lisa.
The code is already a nest of special cases. It won't hurt the pristine nature of the perfect code to add a small check and NOT mishandle one thing that is erroneously treated as a bounce.
but that ignores a core point.
"can do" is one thing. Can it be done? sure. But the real question is "should do", and it should be clear now that many of us feel it's the wrong thing to do on a philsophical level. Just because you CAN do something doesn't make it something you OUGHT to do, or the right thing.
I guess I'll buy a Python book and do it myself.
which is always an option, but it doesn't solve the problem. in fact, it encourages the wrong behavior to continue. your choosing quiet over justice (to misquote bill cosby) only makes it worse for everyone else, because it doesn't help the common good of fixing the baseline problem by encouraging the ISP to fix its stupid mailer.
And you're welcome to make that choice -- but don't get pissed at the project for not helping you do something the project sees as not an improvement or bad for the common good.
On May 4, 2004, at 10:38 AM, Bob Puff@NLE wrote:
If their ISP is broken enough that it generates bounce messages, then their unsubscription problem isn't mine.
it's not always easy to convince their users of that.
Which ties back to the original problem. Those "warning" not-really-bounces are anachronisms of the days when all this was tied to UUCP. Basically, they should die. the only way you convince sites to fix THEIR problems is to convince their users to whine enough to make them care. You can't do that if you "fix the problem in Mailman" by making it go away. Think about what behavior your reinforcing when you make a change, and whether that's the behavior you want to encourage.
the same thing is happening with anti-spam and anti-virus tools, who seem to think they "fix" the problem by bouncing crap into everyone else's mailboxes. my current thought on that is:
http://www.plaidworks.com/chuqui/blog/001447.html
which basically boils down to "if it looks like a bounce and quacks like a bounce and swears like a bounce, then dammit, it's a bounce".
And the only way to make THEM fix their damned systems to not bounce stuff that shouldn't bounce is to make it a visible problem to them. You don't do that by "fixing" mailman. Unfortunately, it'll cause some pain for users, but my feeling is, if their stuff is bouncing and they odn't realize it, that's a bigger problem they SHOULD be warned about,a nyway.
so my policy is now simple: if you bounce it back, I'll treat it like a bounce. If it has the word "spam" in it anywhere, it'll be treated like a complaint against my server, and suffer immediate unsubscription. if that's not what you (the user/subscriber) wanted, then complain to YOUR admins, since tehy're the ones that did it. I'm just not trying to second-guess them any more and figure out which bounces are real, and which ones aren't. if they send it, they must mean it.
and I suggest Mailman as a package take that approach, if we want to have any hope of convincing admins to get their bleeding act together. Because if we wallpaper over it in the bounce processor, we give them no motivation to fix it, do we? and what really ought to be fixed?
Tweaking this stuff in mailman is dealing with a symptom, but not encouraing the real problem to be looked at.
On Tue, 2004-05-04 at 13:48, Chuq Von Rospach wrote:
And the only way to make THEM fix their damned systems to not bounce stuff that shouldn't bounce is to make it a visible problem to them. You don't do that by "fixing" mailman. Unfortunately, it'll cause some pain for users, but my feeling is, if their stuff is bouncing and they odn't realize it, that's a bigger problem they SHOULD be warned about,a nyway.
BTW, with MM2.1.5, users will have more knowledge at their disposal to complain to their ISPs because the probe message will contain the last bounce we received for them. So if it's a warning that's causing them to get disabled (or to get the probe), they'll know it.
-Barry
Chuq Von Rospach <chuqui@plaidworks.com> writes:
Which ties back to the original problem. Those "warning" not-really-bounces are anachronisms of the days when all this was tied to UUCP. Basically, they should die. the only way you convince sites
It doesn't really matter *why*, by god. The fact is they are here, they are in the RFCs and we should bloody well deal with it. The DSN RFC specifies that warnings exist, and we should be treating them as warnings, not as errors.
If we don't want delay notifications, then why are we not specifying "NOTIFY=FAILURE" when sending the message to the MTA? (ESMTP "NOTIFY" commands are supposed to propagate down the line whenever possible.)
RFC 3461, Page 7:
"For compatibility with SMTP clients that do not use the NOTIFY facility, the absence of a NOTIFY parameter in a RCPT command may be interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY."
Don't blame the MTAs for doing what is *defined* as correct and acceptable.
(BTW, we should consider using ENVID [perhaps in addition to VERP], if we want some help processing bounces.)
All this bitching and whining about not wanting to cope with the errors/warnings we get back ("*wah* it's *hard*") is a little ridiculous when we haven't even made a cursory effort to ask for only the ones we care about.[1]
Darrell
[1] yes, not all MTAs will honor it. so what? If we're actually making an effort then the "all bounces are fatal" contingent might have a point, but not until then.
"Chuq" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
Chuq> my current thought on that is:
Chuq> http://www.plaidworks.com/chuqui/blog/001447.htmlMy now-ancient thought on this is
http://turnbull.sk.tsukuba.ac.jp/Tools/Attitude/Warning, it swears like a bounce.
Chuq> so my policy is now simple: if you bounce it back, I'll
Chuq> treat it like a bounce. If it has the word "spam" in it
Chuq> anywhere, it'll be treated like a complaint against my
Chuq> server, and suffer immediate unsubscription.Thank you for taking point on this. I get so tired of the "spam fighters" who produce more unwanted mail than they receive!
Chuq> and I suggest Mailman as a package take that approach, if we
Chuq> want to have any hope of convincing admins to get their
Chuq> bleeding act together.If you want that to get anywhere, you're going to have to sharpen up the language, though. Many users have very little power over their ISP and strong reason not to change (their ISP also provides their income). List admins tend to sympathize with their subscribers. Yes, we need to take the long view, but we don't want to go destroying villages to save them, either.
Also, it's not really the mail admins. I know a few "incompetent" admins, but really they're just average dudes who lack the time. They _must_ cut down the spam and virus flow, so they choose a package that has some reputation for doing just that, install it, and dismiss the occasional complaint about excessive bounces or lost mail due to false positives as cranks and casualties of war.
IMO, it's not the admins we need to punish, it's the _scanner distributors_ who are providing software that by factory default pollutes the whole 'net.
-- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
participants (9)
-
Barry Warsaw -
Bob Puff＠NLE -
Brad Knowles -
Carson Gaspar -
Chuq Von Rospach -
Darrell Fuhriman -
J C Lawrence -
Paul Tomblin -
Stephen J. Turnbull