Postfix delayed notification not recognized.

[M-a]

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.

[http://sourceforge.net/tracker/index.php?func=detail&aid=863989&group_id=103&atid=100103]

[Barry Warsaw (barry)]

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.

[M-a (m-a)]

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?

[M-a (m-a)]

Urgh. Did I say I have these narrow edit forms and line
breaking behind my back without preview? Please apologize
the awful formatting.

[Mark Sapiro (msapiro)]

m-a's comments from 2003-12-28 are correct. The 'Stop'
signal was not being passed from BouncerAPI to the
BounceRunner. This has been fixed in CVS and will be correct
in Mailman 2.1.8.