| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
relative paths, mainly GetScriptURL->the appropriate replacement.
Now I'm done w/ checkins, and I'm going to test the current snapshot.
|
| | |
|
| |
|
|
|
|
|
|
| |
candidates structure, so the addresses are all pre-processed similarly
(but the actions are still HandleBouncingAddress() or
RegisterBounce()).
Fixed a few bounce log messages that were missing some context.
|
| |
|
|
|
|
|
| |
do so.
Added a copy of the GNU GPL.
Added information about mailman-users in README, and reworded some text in there (made the credits less verbose... perhaps they should move to a credits file?)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
different line than the cue. Thus we have to use two separate checks:
- One regex, 'separate_cue_1', to identify this as an failure notice.
The flag var, 'check_prospects', is set if this regex triggers.
- Another regex, 'separate_addr_1', adds the addr to prospects if
triggered.
Prospects are only used when 'check_prospects' has been set, to ensure
that the message being examined is in fact a failure notice.
(The two hosts i'm dealing, parrot and glyph, happen to run run
berkeley sendmail 8.8.5, which happens to issue failure notices like
this. I would not be surprised if more recent sendmails did, too...)
|
| |
|
|
|
|
|
|
| |
the remaining number of bounces a member is allowed (within the
stipulated time frame) before exceeding the limit. If this is right,
with the other bounce-handling refinements i feel a lot more confident
about predicatable, well-mannered behavior from the bounce management
stuff...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bouncing address - before sending the notice, check whether the
bouncing address is among the list owner addresses.
And otherwise, include (attach) a copy of the actual bounce notice in
the admin-action message. Otherwise there is no record the
administrator can examine.
Finally, send both failed and successful admin-action notifications to
the list administrator. Before, failed action (e.g. inability to
locate the specific user) were sent to the mailman site admin - this
was while i was debugging the bounce handling, but it looks a lot
better now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ScanMessage(): added final-step massage of all candidates to remove
encompassing <, > angle brackets, if any, and check against already
processed candidates.
(In order to change something to enable a checkin i made a spelling
change of something trivial that i resisted for a while - substituted
"message_grokked" for "message_groked". I'm pretty sure the double k
is right, but don't have a copy of stranger in a strange land happy to
check. Anyway, i keep reading "groked" like it would rhyme with
"stoked", which just can't be right...-)
|
| |
|
|
|
|
|
|
|
|
|
| |
disabled. The idea is that numerous outstanding bounces do not each
require renotification of the admin.
DisableBouncingAddress(), RemoveBouncingAddress(): changed return
signatures to indicate whether email notification is necessary for
this action, and in Disable version, indicate not necessary when user
is already disabled. In all other cases, notification is indicated,
whatever the status.
|
| |
|
|
|
|
|
|
|
| |
extraction, with testing. We now avoid all the silly elipses cases...
(Unfortunately i could not test the bounce handling on glyph due to
some subtleties in the sendmail setup. Fortunately, bounce handling
is a sufficiently uncommon event that i could work on the production
system without much fear of disruption.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of bounce violators, and also reduce if not eliminate the number of
invalid address targets.
.ScanMessage(): Instead of handling each email addr as it's encountered,
collect together all the candidates and go through them all at the
end, rejecting duplicates. This way, candidates found repeatedly in
different cases won't be processed multiple times.
.ExtractBouncingAddr(): Prevent a commonly recurrent aberrant address
gleaning, eg: "<klm@python.org>..." - many error notice lines have
that elipsis after the address, and it was not being adequately
filtered. Now it is.
|
| |
|
|
|
|
| |
look like an erroneous application of a non-existent function.
Minor spelling change - "relevent_text" => "relevant_text".
|
| |
|
|
| |
__version__ info.
|
| | |
|
| |
|
|
|
| |
Tracking change of SendTextToUser() option, errorsto =>
add_new_header.
|
| |
|
|
|
|
| |
Wrapped a bunch of long lines.
(Sometime soon the regexps are going to have to be converted to re.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
disabled, rather than removed, and (2) that option can be accompanied
by email to the admin, or not, but the removal option always entails
email to the admin. (Email to the admin was previously not
implemented, though there were options that were supposed to do it.)
Mostly implemented in new method, .HandleBouncingAddress(), which
dispatches to RemoveBouncingAddress() or DisableBouncingAddress().
Improve logging - more terse messages, but more comprehensive
coverage.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
as an alternative to removal:
Option minimum_post_count_before_removal =>
minimum_post_count_before_bounce_action.
Option automatically_remove => automatic_bounce_action.
New method DisableBouncingAddress(), as alternative to
RemoveBouncingAddress().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
it already exists and is unwritable), using safe .LogMsg() in the
"bounce" category, instead.
Rationalized the bounce reporting a bit.
|
| | |
|
| |
|
