Bugs item #863989, was opened at 2003-12-21 16:49 Message generated for change (Comment added) made by m-a You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=863989&group_id=103 Category: bounce detection Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Matthias Andree (m-a) Assigned to: Nobody/Anonymous (nobody) Summary: Postfix delayed notification not recognized. Initial Comment: Hi, I am running Mailman 2.1.3 (stable) with Postfix 2.0.16-20031022. It seems to be running fine with the VERP patch (it is comfortably surprising to see how much Mailman has matured since the unusable 1.1 version - I hated 1.1 but I do like 2.1! You've done wonderful work.) However I have one problem that I cannot resolve myself: Mailman apparently does not parse Postfix' delayed notification which is apparently RFC-1894 conformant (Postfix hasn't been updated to RFC-3464 yet). On superficial inspection, it looks as though Mailman's Bouncers/DSN.py should handle it and return "Stop", as but I'm getting this "uncaught bounce" message which I interpret as "haven't figured anything reasonable from this bounce". The unintelligible bounce is attached and has had mail addresses changed (sed) and the delayed mail header removed for privacy reasons. I can provide the full message to a developer on request, but I cat not put it into a public bug tracker. The MIME structure of Postfix' delay notification is: 1 multipart/report 1.1 text/plain 1.2 message/delivery-status 1.3 text/rfc822-headers The message/delivery-status part has "Action: delayed" in the 2nd header block. See for yourself. Am I misunderstanding Mailman or is Mailman misunderstanding Postfix? Thanks in advance. ----------------------------------------------------------------------

Comment By: Matthias Andree (m-a) Date: 2003-12-29 04:38

Message: Logged In: YES user_id=2788 Hum, looks like this issue isn't Postfix specific, but affects all systems that send a delay notification. "logs/bounce" contains: Dec 27 20:35:45 2003 (2053) bounce message w/no discernable addresses: <mumble> Dec 27 20:35:45 2003 (2053) forwarding unrecognized, message-id: <mumble> If I save exactly this mail (I checked the Message-ID) and feed it to onebounce.py, I'm getting "DSN got Stop", so that part is fine. I've dug a bit deeper, and noticed a difference between onebounce.py and BouncerAPI.ScanMessages. See lines 65ff in BouncerAPI.py: addrs = sys.modules[modname].process(msg) if addrs is Stop: # One of the detectors recognized the bounce, but there were no # addresses to extract. Return the empty list. return [] I wonder if ScanMessages() is doing the right thing, mapping Stop to []. Evidently, the BounceRunner assumes [] is a parse failure (no addresses returned) and ultimately forwards the "delay notification" to the admin contrary to original DSN.py "Stop" intent. To me, it seems as though ScanMessages needed a fix that allows it to propagate both states, "bounce recognized, no addresses" and "bounce unrecognized", back to its caller. I wonder if the "Stop" condition should be exposed to the BounceRunner or some other interface extension in ScanMessages. What do you think? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-27 07:50 Message: Logged In: YES user_id=12800 Hmm, I get Stop when I run this message through the DSN.py bounce processor, so as near as I can tell, this is working properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=863989&group_id=103