[ mailman-Bugs-863989 ] Postfix delayed notification not recognized.
SourceForge.net
noreply at sourceforge.net
Sun Dec 28 22:40:37 EST 2003
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:40
Message:
Logged In: YES
user_id=2788
Urgh. Did I say I have these narrow edit forms and line
breaking behind my back without preview? Please apologize
the awful formatting.
----------------------------------------------------------------------
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
More information about the Mailman-coders
mailing list