why treat action: delayed in DSN as an unrecognized bounce?
I am using MM 2.1.4 and have been getting some "Uncaught bounce notification" messages from it. The MTA is Postfix (a 2.1.0 snapshot as of 20040209) and it is the local MTA (i.e. on the same machine and in the same administrative domain as MM) that is generating the bounces, complete with DSNs.
The issue seems to be that the Action: in the DSN is "delayed". These delivery notifications are the "we have been trying for 4 hours and have not been successful but will try for 5 days before giving up" kind of notifications.
Looking into the DSN handling code for MM, I see that in DSN.py, the check() method returns "Stop" if action == 'delayed'. The caller (BouncerAPI.py:ScanMessages()) then returns an empty list if the callee returns Stop, which triggers the "unknown bounce" processing.
Why is delayed not handled more gracefully than treating it as an unknown bounce type? Or am I totally missing something here?
Thanx, b.
At 2:32 PM -0400 2004-07-04, Brian J. Murrell wrote:
Why is delayed not handled more gracefully than treating it as an unknown bounce type? Or am I totally missing something here?
Search the archives. I believe you'll find that the answer is that you (the mailing list administrator) should have control over the MTA, and if you don't want warnings to be treated the same as bounces, then you should configure the MTA so that it doesn't generate warnings.
But you should search the archives to get the full picture of previous discussions.
-- 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 Sun, 2004-07-04 at 21:52 +0200, Brad Knowles wrote:
Search the archives.
I did.
I believe you'll find that the answer is that you (the mailing list administrator) should have control over the MTA,
I do -- to the extent that the MTA gives me that control.
and if you don't want warnings to be treated the same as bounces, then you should configure the MTA so that it doesn't generate warnings.
To say "in order to not treat warnings as errors, disable warnings" is, respectfully, silly. Warnings should be heeded but they do not necessarily indicate that they should be treated as errors. Where in life is it valid to say "to not treat warnings as errors, ignore warnings"?
But you should search the archives to get the full picture of previous discussions.
You are probably referring to the recent discussion of May 2004. I did read it. It did not seem to indicate any real solution (other than ignore warnings).
And for mailing list mail, it is _perhaps_ valid to simply disable warnings, so I did look into how to do this. I did not seem to find any way to disable warnings for a given Precedence: level in Postfix. i.e. for Precedence: list only, disable warnings, but for regular Precedence: I do want warnings.
I don't think this changes the fact that MM should deal with warnings without barfing them out as "unknown bounces". They are known. The code is there to "know" them. MM just prefers to not deal with them, which I think it should, even if it's to simply ignore them.
b.
At 4:16 PM -0400 2004-07-04, Brian J. Murrell wrote:
I don't think this changes the fact that MM should deal with warnings without barfing them out as "unknown bounces". They are known. The code is there to "know" them. MM just prefers to not deal with them, which I think it should, even if it's to simply ignore them.
I'm not entirely sure that I disagree with you, but this is functionality not currently found in Mailman, and this is an open source project.
If you want to contribute code to make this change happen, and post that as a patch in the SourceForge patch system for Mailman, I'm sure that it would be gladly accepted. No guarantees that this functionality would ever be incorporated, but this would be the most likely way to ensure that this would happen.
Otherwise, you're at the mercy of the developers on the project. This project is not a full-time job for anyone (so far as I know), and people have to squeeze in what work that they can, when they can. Right now, the primary focus in Mailman is on the upcoming version 3 stuff, and any work on patching/fixing the current version is going to have to be something pretty major.
-- 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 Sun, 2004-07-04 at 22:43 +0200, Brad Knowles wrote:
I'm not entirely sure that I disagree with you,
OK. So I am not totally off my nut then. :-)
but this is functionality not currently found in Mailman, and this is an open source project.
Indeed. Very fair points.
If you want to contribute code to make this change happen, and post that as a patch in the SourceForge patch system for Mailman, I'm sure that it would be gladly accepted. No guarantees that this functionality would ever be incorporated, but this would be the most likely way to ensure that this would happen.
Right. I guess I just wanted to make sure my analysis was correct first. Seems it is then.
Otherwise, you're at the mercy of the developers on the project. This project is not a full-time job for anyone (so far as I know), and people have to squeeze in what work that they can, when they can.
I hear ya. I'm in that same boat. :-)
Right now, the primary focus in Mailman is on the upcoming version 3 stuff, and any work on patching/fixing the current version is going to have to be something pretty major.
So will version 3 be the next release? i.e. nothing until then? Does v.3 address this issue at all or is it pretty much the same in 3?
The next question is, what should MM do with delivery warnings? Is there any merit to doing anything but ignore them silently? That begs the question of why even issue them from the MTA of course, but perhaps not all MTAs are flexible enough to disable those warnings for or below a certain Precedence level. Perhaps for regular mail those warnings are still wanted. Postfix falls into this category as far as I can see, but then I am only a casual user of Postfix -- maybe it is configurable.
b.
At 5:08 PM -0400 2004-07-04, Brian J. Murrell wrote:
So will version 3 be the next release? i.e. nothing until then? Does v.3 address this issue at all or is it pretty much the same in 3?
I understand that version 3 is going to be a pretty big change, although I don't know if it's going to be a complete re-write. There may or may not be a 2.1.6 released before version 3 arrives, but I wouldn't want to take any bets either way.
The next question is, what should MM do with delivery warnings? Is there any merit to doing anything but ignore them silently?
I'm not sure that there is anything more we can do with them. Hence the suggestion not to generate them, if you don't want them. Of course, most MTAs will only generate one additional warning beyond the bounce itself, so this should have relatively minimal impact if you don't ignore them. If it does have an impact, the other option would be to change the bounce process handling so that you increase the required score by the number of warnings that might be generated, and the impact of warnings should be eliminated.
That said, for an MTA which is shared amongst some mailing lists and some real users, it might be better to configure Mailman to ignore warnings than to depend on the MTA not to generate them.
-- 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 Sun, 2004-07-04 at 23:39 +0200, Brad Knowles wrote:
I'm not sure that there is anything more we can do with them.
Indeed. It is only a warning of non-delivery. The bounce is the important one.
Hence the suggestion not to generate them, if you don't want them.
If that is doable, I agree, but to your point below...
Of course, most MTAs will only generate one additional warning beyond the bounce itself, so this should have relatively minimal impact if you don't ignore them.
You would think but if one is generated for every message for every recipient that does not take delivery within (for example) 4 hours, it does get quite annoying.
If it does have an impact, the other option would be to change the bounce process handling so that you increase the required score by the number of warnings that might be generated, and the impact of warnings should be eliminated.
But the issue is not really in thresholds and unsubscriptions and so forth but simply that the list manager's mailbox gets littered with these "unrecognized bounce" messages. Simply having MM ignore them would be sufficient methinks.
That said, for an MTA which is shared amongst some mailing lists and some real users, it might be better to configure Mailman to ignore warnings than to depend on the MTA not to generate them.
Right. And it seems that a simple "continue" rather than "return Stop" if action == 'delayed' should be the ticket -- not being an MM hacker at the moment anyway. :-)
b.
participants (2)
-
Brad Knowles -
Brian J. Murrell