Merge lp:~amk/mailman/bounce-analysis into lp:mailman/2.2
Proposed by
A.M. Kuchling
| Status: | Work in progress |
|---|---|
| Proposed branch: | lp:~amk/mailman/bounce-analysis |
| Merge into: | lp:mailman/2.2 |
| Prerequisite: | lp:mailman/2.1 |
| To merge this branch: | bzr merge lp:~amk/mailman/bounce-analysis |
| Related bugs: |
To post a comment you must log in.
Revision history for this message
| Mark Sapiro (msapiro) wrote | # |
Unmerged revisions
- 1074. By A.M. Kuchling
-
Add message-id to all the bounce processing paths
- 1073. By A.M. Kuchling
-
Merge
- 1072. By A.M. Kuchling
-
Merge
- 1071. By A.M. Kuchling
-
Add explanatory comment
- 1070. By A.M. Kuchling
-
Merge 2.1 changes
- 1069. By A.M. Kuchling
-
Merge
- 1068. By A.M. Kuchling
-
Don't include comma in sender's e-mail
- 1067. By A.M. Kuchling
-
Convert to use dictionaries instead of a class instance
- 1066. By A.M. Kuchling
-
Read post log; record list name and sender e-mail
- 1065. By A.M. Kuchling
-
Implement parsing of Postfix log files
I am looking at merging these changes into the 2.1 branch.
It looks like I'll be changing a couple of other bounce log messages to include listname at the beginning. I don't see much harm coming from adding message-id at the end. It's much better than inserting something in the middle of a message.
There is a consistency issue however. These changes attempt to find and log the message-id of the message that was bounced. There are already bounce log messages for unrecognized bounces that log the message-id of the 'bounce' message itself. In the case of an unrecognized message that was actually spam or a misdirected message to the list-bounces address, I think this is OK as the message is not a return of a list message, but in the case of a true bounce that is not recognized, we have this inconsistency.
It would be difficult to change the logging of unrecognized bounces, since by definition, we don't know what they are. We could use Bouncer.
A second inconsistency is the unrecognized bounce entries use 'n/a' for an unavailable message id, and these changes use 'unknown'.
I don't think these are necessarily show stoppers, but I am interested in what people think about them.
/Mark