[ mailman-Bugs-863989 ] Postfix delayed notification not recognized.

[SourceForge.net]

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