summaryrefslogtreecommitdiff
path: root/Mailman/Bouncer.py
Commit message (Collapse)AuthorAgeFilesLines
...
* Use better syslog() calling convention.bwarsaw2001-06-271-29/+26
|
* HandleBouncingAddress(): Instead of passing in the list's preferredbwarsaw2001-05-181-3/+3
| | | | | language, simple pass in self; maketext() digs the preferred language out of the list object.
* HandleBouncingAddress(): Mark some more strings for translation.bwarsaw2001-05-011-9/+12
| | | | | Original patch by Juan Carlos Rey Anaya after bug report by Patrick Timmons. Patch modified by Barry.
* Next round of big i18n patches.bwarsaw2001-02-281-68/+78
| | | | | | | | | | | | | | Untabification. GetConfigInfo(): Reformat many of the strings to be triple-quoted instead of adjacent string concat. Fix the Utils.maketext() calls to pass the language in as a keyword argument. Fix some _() wrappings to use local variables. [Note this file may still have problems -- e.g. Utils.GetCharSet()]
* De-string-module-ify.bwarsaw2001-02-151-12/+12
| | | | | | References to HandlerAPI module removed. Use new mimelib interface.
* Latest set of I18N patches from jcrey. Specifically,bwarsaw2000-12-261-3/+3
| | | | | HandleBouncingAddress(): Call maketext() with list's preferred language. Don't hardcode Content-Type: charset to "us-ascii".
* First integration patch for Juan Carlos's translatable string changesbwarsaw2000-12-071-19/+19
|
* HandleBouncingAddress(): Be more robust about getting the messagebwarsaw2000-10-051-3/+13
| | | | | | | body. If the msg object is one of our Message.Message's it'll have a body attribute. If it's a mimetool.Message, it'll have a rewindable fp attribute. But just to be sure, default the body to something reasonable.
* RegisterBounce(): Remove the saveifdirty flag from the argument list,bwarsaw2000-09-081-73/+65
| | | | | | | | | | | | and unwrap from the try/finally saving the mailing list. We'll assume the caller always saves the list. HandleBouncingAddress(): Don't do a msg.rewindbody()/msg.fp.read() to get the text of the message. When called from qrunner, the file handle will be closed, and this will cause a fatal error in SMTPDirect, which in turn causes multiple sends until all offending email addresses are disabled. The right way to do this now is to use the msg.body attribute. This closes SF bugs #111843 and #111176.
* HandleBouncingAddress(): GetAbsoluteScriptURL() => GetScriptURL(...,bwarsaw2000-08-011-1/+1
| | | | absolute=1)
* RegisterBounce(): cosmeticbwarsaw2000-07-211-2/+1
|
* Convert all uses of mlist.LogMsg() to the new syslog() interface.bwarsaw2000-06-021-33/+31
|
* Update the copyright lines to include the years 1999 & 2000.bwarsaw2000-03-211-1/+1
|
* HandleBouncingAddress(): Because this message object is now abwarsaw1999-12-161-1/+3
| | | | | | | | mimetools.Message (see scripts/mailowner), the body attribute doesn't get set. Fish the body out by using msg.rewindbody(); msg.fp.read(). We /really/ need one Message object that is an amalgam of rfc822.Message, mimetools.Message, and multifile.MultiFile!
* Rip out all the actual bounce detection code (moved tobwarsaw1999-12-091-155/+5
| | | | | Bouncers/Catchall.py) in the port to the new bounce detection architecture.
* RegisterBounce(): Added optional saveifdirty flag, which defaults tobwarsaw1999-11-301-3/+2
| | | | | | true. SMTPDirect sets this to zero so the list isn't save between each bounce registration. SMTPDirect does the save after processing all delivery failures.
* Convert message delivery to pipeline architecture by usingbwarsaw1999-11-241-11/+13
| | | | | HandlerAPI.DeliverToUser() for fast track delivery of the notification messages.
* Fixed problem with MIME bounces not containing any MIME boundaries athmeland1999-07-011-1/+6
| | | | all (these used to raise an IndexError).
* Do *not* remove immediately for all 550 class errors. These willklm1999-03-101-1/+1
| | | | | | | | | occur for transient things, like procmail errors or "can't create output". In general i'm dubious about the immediate-removal class, and would lean towards treating all bounces the same, with action on a cumulative incidence, so any transient problems get time to be fixed...
* Made the call to FindMatchingAddresses pass the dict bounce_infocotton1998-11-231-1/+1
| | | | | | instead of the list bounce_info.keys() as the second arg to fit the new FindMatchingAddresses signature. scott
* .RegisterBounce(): I revised the criteria for what makes a bounceklm1998-11-181-7/+10
| | | | | entry stale - now it's when the entry has been pending for five times the minimum_removal_date.
* .InitVars(): Include a comment explaining the bounce_info structure,klm1998-11-171-58/+92
| | | | | | | | | | | | | | | | at least, as best as i can glean. .RegisterBounce(): Ensure that self.Save() is called if the bounce history stats change within the routine. This was not always happening before, so that changes in the stats could be lost (depending on whether some other method saved the config somewhere down the line), leading to inconsistent behavior. I fixed that, and added a loop at the top that culls stale entries from the db whenever a bounce is detected, so we aren't monotonically accumulating bounce histories over the lifetime of the list! I also added a docstring and several less cryptic comments, to try to be clearer about what's going on here.
* Make the disabled notice less ambiguous - reorganized so it's clearklm1998-11-051-1/+1
| | | | | | | | | | | | | | | what phrase is or is not negated: old: Mailman-Checkins member klm@python.org disabled due to bounces old: Mailman-Checkins member klm@python.org NOT disabled due to bounces vs new: Mailman-Checkins member klm@python.org bouncing - disabled new: Mailman-Checkins member klm@python.org bouncing - NOT disabled In the NOT version of the old, it would seem to be saying that the member was NOT disable _because_ of the bounces, not the case at all.
* made reenable.txt refer to the admin membership page instead of the listinfocotton1998-10-131-1/+1
| | | | | page for altering the member's status. scott
* fixed typo in the regex email pattern (it wasn't matching addressescotton1998-10-131-2/+3
| | | | | | with an 's' in the username part). added a bounce pattern to simple_bounce_patterns scott
* Bouncer.HandleBouncingAddress(): Convert to using Utils.maketext() templates.bwarsaw1998-07-061-48/+46
|
* Convert all module names to their new names.bwarsaw1998-06-191-12/+13
| | | | Removed RCS crud
* Whoops, I forgot to check these in. They're changed to handleviega1998-06-031-2/+2
| | | | | relative paths, mainly GetScriptURL->the appropriate replacement. Now I'm done w/ checkins, and I'm going to test the current snapshot.
* Fixed a typo in the zipcode.viega1998-05-261-2/+2
|
* .ScanMessage(): Consolidated BOUNCE and REMOVE handling on themailman1998-05-261-34/+29
| | | | | | | | 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.
* Added copyright notices to all source files where I am legally entitled to ↵viega1998-05-251-1/+18
| | | | | | | 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?)
* Slight simplification of remaining-messages log notice.mailman1998-05-241-3/+2
|
* Added provision for a bounce message where the email address is on aklm1998-05-241-3/+23
| | | | | | | | | | | | | | | | 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...)
* .RegisterBounce(): I think this corrects the bounce log reporting ofklm1998-05-211-3/+4
| | | | | | | | 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...
* Prevent bounce loops when admin-action recipient is itself theklm1998-05-211-30/+65
| | | | | | | | | | | | | | | 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.
* Neglected to mention on last checkin:mailman1998-05-201-10/+10
| | | | | | | | | | | | | 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...-)
* Do not send "user disabled" notices to admin when user is alreadymailman1998-05-201-17/+35
| | | | | | | | | | | 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.
* .ScanMessage(): Further robustification of the bounced-message addressmailman1998-04-231-4/+10
| | | | | | | | | 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.)
* These changes should reduce, if not eliminate, the duplicate handlingklm1998-04-231-14/+13
| | | | | | | | | | | | | | | 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.
* .RegisterBounce(): Missing '%' was making a string format operationklm1998-04-101-12/+11
| | | | | | look like an erroneous application of a non-existent function. Minor spelling change - "relevent_text" => "relevant_text".
* Preparing to package a distribution - add a module docstring andmailman1998-04-091-0/+4
| | | | __version__ info.
* Call to SendTextToUser() requires "add_headers" instead of "add_to_headers"mailman1998-04-081-2/+2
|
* Added new-format descriptive header, as string in options list.klm1998-04-071-4/+7
| | | | | Tracking change of SendTextToUser() option, errorsto => add_new_header.
* Use new .DeleteMember() arg to indicate whence this deletion came.mailman1998-04-031-14/+24
| | | | | | Wrapped a bunch of long lines. (Sometime soon the regexps are going to have to be converted to re.)
* Finally fix bounce handling so (1) there is an option for users to bemailman1998-03-271-26/+96
| | | | | | | | | | | | | 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.
* Change bounce-handling mechanism to offer disabling of user account,mailman1998-03-261-13/+24
| | | | | | | | | | | | 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().
* Looks like bounce handling does not work like options advertise - inmailman1998-03-201-7/+7
| | | | | | | | | | | | | | | | | | | 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.
* Remove use of '/tmp/bounce.log' file (which will knock over mailman ifmailman1998-03-191-18/+32
| | | | | | | it already exists and is unwritable), using safe .LogMsg() in the "bounce" category, instead. Rationalized the bounce reporting a bit.
* Utilize default settings from mm_cfg module.mailman1998-02-261-14/+9
|
* Initial revisionmailman1998-02-251-0/+220
generated by cgit v1.2.3-70-g09d2 (git 2.51.2) at 2025-11-08 20:34:20 +0000