Public bug reported:
The DSN bouncer handler can't seem to parse out when a bounce is generated due to an inactive google account.
See attached bounce file for example.
** Affects: mailman Importance: Undecided Status: New
** Attachment added: "bounce from a inactive googlemail user" https://bugs.launchpad.net/bugs/886296/+attachment/2585519/+files/googleboun...
The example DSN attached is a "delay" message. If Mailman did recognize it, it would just be ignored anyway. If we are going to recognize it, it would help if we had the entire, raw message source with all headers rather than what appears to be an MUA's rendering of it.
More importantly, what does the ultimate "I give up" DSN look like?
** Changed in: mailman Status: New => Incomplete
** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro)
** Also affects: flufl.bounce Importance: Undecided Status: New
** Changed in: flufl.bounce Status: New => Incomplete
Yes, I think ideally this kind of message would best be ignored instead of passed on to the admin unprocessed.
From downstream report about the ultimate "I give up" DSN:
"I haven't seen any. Maybe the final error message is recognized properly, maybe the user can re-enable his Google account before time-out."
email showing issue
** Attachment added: "google-delay.mbox" https://bugs.launchpad.net/mailman/+bug/886296/+attachment/2587446/+files/go...
What Mailman version is failing to recognize this DSN?
It turns out that this DSN has been recognized as a warning only and ignored since Mailman 2.1.11.
** Changed in: mailman Importance: Undecided => Low
** Changed in: mailman Status: Incomplete => Fix Released
** Changed in: mailman Milestone: None => 2.1-stable
Looks like 2.1.9, so that would explain it. ;(
** Changed in: flufl.bounce Status: Incomplete => Fix Released