diff options
| author | mailman | 1998-03-20 18:12:34 +0000 |
|---|---|---|
| committer | mailman | 1998-03-20 18:12:34 +0000 |
| commit | 63494efb15c760c21f6f73bfb2d9cb0f2b5e4717 (patch) | |
| tree | 899ba27e20418b34287def0cb9163bc4da5d596d /modules/mm_admin.py | |
| parent | 07b3b648de152bee0b154e7fca2c39adaad0effe (diff) | |
| download | mailman-63494efb15c760c21f6f73bfb2d9cb0f2b5e4717.tar.gz mailman-63494efb15c760c21f6f73bfb2d9cb0f2b5e4717.tar.zst mailman-63494efb15c760c21f6f73bfb2d9cb0f2b5e4717.zip | |
Looks like bounce handling does not work like options advertise - in
particular, "Don't remove, notify me" still *does* do the removal.
Sigh.
The right way to set this up will take some thought, but i think my
first cut fix will be, when this option is selected, to just disable
the user, and send a note to the admin. That way, the admin won't
just get extra notes accompanying continuing bounce results for the
user... I may get to this quick fix soon.
The long term (and fairly attractive) fix is to make a bounce-handling
subsystem which collects bounce messages and classifies them according
to a admin-configurable template, taking actions like disabling or
removing the user, notifying the admin, etc, when admin-configured
thresholds are reached. The admin interface could be handled very
like the admin-requests mechanism, with a page for bounce
administration and a periodic notice of pending bounce admin stuff.
Diffstat (limited to 'modules/mm_admin.py')
0 files changed, 0 insertions, 0 deletions