summaryrefslogtreecommitdiff
path: root/Mailman/MailCommandHandler.py
Commit message (Collapse)AuthorAgeFilesLines
...
* Update imports, and convert to new Message.Message objectbwarsaw1999-11-101-10/+7
|
* ParseMailCommands(): Quickie patch to allow quotes around the commandbwarsaw1999-09-081-0/+10
| | | | | | | part of the email command. This means "help" [sic] works and you don't have to say: Send the word "help" (sans quotes) to ...
* ProcessConfirmCmd(): Confirmation of an subscription for an addresshmeland1999-07-011-1/+4
| | | | | | can bomb out with MMAlreadyAMember if the address has already been subscribed by some other mechanism after the pending confirmation was registered. Catch this and reply politely.
* The "password" mail command can now also be used for having one'shmeland1999-07-011-2/+14
| | | | member password mailed back -- if given with no arguments.
* AddToResponse(): Added new optional arg `prefix'. Changed truncationhmeland1999-06-131-87/+95
| | | | | | | | | to be a per-line operation, done after addition of prefix. AddError(): Use AddToResponse with the new `prefix' argument to make sure the prefix is added to all the lines of the error message. Added info on the `help' mail command to the response indicating processing problems. Quite a lot of buglet fixes and general cleanup.
* ParseMailCommands(): In the case that the maximum number of commandhmeland1999-06-041-2/+2
| | | | | lines is reached, inclusion of the rest of the original message was being truncated (and was using a strange line prefix). Fixed.
* ProcessUnsubscribeCmd(): Catch Errors.MMNotAMemberError, which is whatbwarsaw1999-05-061-2/+1
| | | | SecurityManager raises when the user addr isn't on the list.
* eradicate "maillist" as a nounbwarsaw1999-05-051-1/+1
|
* ParseMailCommands(): make the confirmation regexp whitespacebwarsaw1999-04-281-2/+2
| | | | | insensitive. Fixes the problem for Outlook wrapping the Subject lines.
* ParseMailCommands(): Two small changes. First, ignore case whenbwarsaw1999-04-271-2/+2
| | | | | | | | | | regexp matching against the confirmation line. This may have to be further extended to ignore differences in whitespace (this was all triggered by potential MS Outlook mungifications). Second, if there /was/ an error, put the whole subject line on it's own line in the error message. This'll make it easier to debug in the future.
* Don't truncate "Subject line ignored" linesbwarsaw1999-04-141-1/+2
|
* ProcessWhoCmd(): Be sure not to truncate the list of members!bwarsaw1999-03-311-2/+2
|
* Lots of changes!bwarsaw1999-03-241-145/+208
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (option_descs, option_info): Provide much more detailed descriptions of the options. Also changed `norcv' to `notmetoo' although the former is still acceptable as an alias. (options): New global to preserve the order that we want to display the options in response messages. These options are in the same order as shown on the membership management admin page. The user option page still needs to be changed to support this order. MailCommandHandler.__init__(): All private variables are fixed to start with double underscore (e.g. __dispatch). Added an __errors ivar to count the number of AddError() calls made. A different error message format is now used, which should be much more concise, and more informative information is provided at the head of error messages. AddToResponse(), AddError(): Both methods now take a final argument `trunc' which says what column to truncate the text to. With trunc=0 no truncation (this is useful for when we use Utils.wrap() to wrap the text). AddError() also now takes a prefix argument, increments self.__error, and essentially calls AddToResponse(). ParseMailCommands(): Some stylistic changes. The line being processed is not placed in the response buffer unless we know it is a valid command. If it's an invalid command, we print the error message more concisely. When `end' is found, include in the response all the following lines that are ignored. If the number of errors exceeds 5, then stop processing the message immediately (don't keep processing more lines). If an unexpected error occurs with a valid command (one that is dispatched), we catch this and include the traceback in the response message. We also send the traceback to the list administrator -- I wonder if this should be the mailman-owner??? We also log the exception. In the error preamble, include human contact information. Several of the Process*Cmd()'s have been modified to work with this new framework, and to provide much more meaningful response messages.
* ProcessSetCmd(): Installed Balazs Nagy's patch to check for membershipbwarsaw1999-02-271-14/+10
| | | | and password before parsing the arguments.
* .SetOptionCommand(): For some reason the options descriptions keys nowklm1998-12-101-17/+21
| | | | | | | includes digest, so the check for the special handling of the digest option was no longer working. I've reinstated that by explicitly checking for that special case first, so now the mailcommand version of digest setting is working.
* .ProcessPasswordCmd(): Niggle - use the derived 'sender' value theklm1998-12-091-5/+4
| | | | routine had mail.GetSender()...
* .ProcessPasswordCmd(): Was not working because .ChangeUserPassword()klm1998-12-091-4/+10
| | | | | | | | | was getting called with the wrong arguments - confirmation of the old password needed to be done in a separate call to ConfirmUserPassword(). (Incidentally, i am hoping that i repaired a problem with the mechanism that pushes the cvs source - this will test it.)
* .ProcessConfirmCmd(): For invalid confirmation numbers, indicate thatklm1998-12-071-2/+11
| | | | confirmations expire after the set number of days.
* removed erroneous and leftover 'import Pending'cotton1998-11-251-1/+0
| | | | scott
* I should have broken this up into 2 checkins because it implements onecotton1998-11-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fix and one addition. Sorry, i realized that too late. This change adds another list conifg variable "admin_notify_mchanges", which is a boolean 0 or 1 and specifies whether or not the list admin gets notifications of subscriptions and unsubscriptions. The functions MailList.DeleteMember and MailList.ApprovedAddMember trigger the delivery if it is turned on for the list or passed in as an optional argument. This way, it is the duty of programs/code that do mass subscriptions/unsubscriptions where this notification may not be appropriate to specify that in the call to .DeleteMember or .ApprovedAddMember. There are 2 new templates, adminsubscribeack.txt and adminunsubscribeack.txt which are used in sending these notifications. Defaults.py.in has a variable "DEFAULT_ADMIN_NOTIFY_MCHANGES" which is set to 0 so that old lists will act the same by default, and the data version is up'ed to 12. versions.py sets the variable if it's not already there for a list. The config info for the admin cgi program for this new variable is set right after the variable for immediate notifications. The second change is a fix where ApprovedAddMember was calling a "self.Save()", which made mass subscribe situiations really far too slow. I removed the .Save() from there and added it to the more outer level code in the following places: bin/convert_list Mailman/ListAdmin.py Mailman/MailCommandHandler.py Mailman/Cgi/admin.py Note that since AddMember can trigger a call to ApprovedAddMember, all the places where AddMember is called needed a .Save() added as well. I need to add a call to .Save() for Mailman/Cgi/subscribe.py as well and will do that in a moment. scott
* This change implements storing list members and digest members ascotton1998-11-191-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dicts instead of lists, which optimizes Utils.FindMatchingAddresses and general membership management, especially for large lists. MailList.py now supplies .GetMembers() and .GetDigestMembers() to supply the data in list form to anything that needs it that way. An new install showed this worked fine with some cursory testing of the cgi's and interactive poking around. A detailed listing of the changes follows: Mailman/Defaults.py.in: change data version to 11 Mailman/Digester.py: initvars now instantiates digest_members as {} instead of [] lines 113-114 and 121-122 now use del This change implements storing list members and digest members as dicts instead of lists, which optimizes Utils.FindMatchingAddresses and general membership management, especially for large lists. MailList.py now supplies .GetMembers() and .GetDigestMembers() to supply the data in list form to anything that needs it that way. Though INSTALL shows up on the changed files section, a diff a few seconds ago didn't show any differences in that file, so I hope nobody changed it in the interim. An new install showed this worked fine with some cursory testing of the cgi's and interactive poking around. A detailed listing of the changes follows: Mailman/Defaults.py.in: change data version to 11 Mailman/Digester.py: initvars now instantiates digest_members as {} instead of [] lines 113-114 and 121-122 now use del list.[digest_]member instead of list.[digest_]members.remove when figuring who to actually send digests to, use list.GetDigestMembers() instead of list.digest_members. Mailman/HTMLFormatter: now uses list.Get[Digest]Members to get subscribers, and length of digested subscribers and regular members MailCommandHandler, SecurityManager,Cgi/handle_opts, Cgi/options: all simple replacements of list.[digest_]members with list.Get[Digest]Members(). Mailman/Cgi/admin.py: mostly simple replacements of list.[digest_]members with the Get..() methods, however, the membership management section now works much quicker and changes digest->nodigest subscriptions via dictionary manipulations. Mailman/versions.py: updates lists to use dicts and changed list.[digest_]members to use the list.Get[Digest]Members() methods. Mailman/Utils.py: added a function "GetPossibleMatchingAddresses" which when fed an address, returns the list of addresses that "smart" address matching would match. changed FindMatchingAddresses(name, list) to use a new signature: FindMatchingAddresses(name, *dicts), where dicts is a list of dictionaries keyed by addresses. Just realized that this would better be FindMatchingAddresses(name, dict, *dicts) so that it enforces atleast 2 args... I'll make that change in a sec. All uses of FindMatchingAddresses have been changed to fit the new arguments. scott ----:**-F1 cvs30458aaa 1:12PM 0.98 Mail (Text Fill)--L59--32%------------------------------------------- ?
* These changes allow case-preserved usernames in email addresses ofcotton1998-10-121-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | list members. I have yet to look at handling of -admin addresses. Also, there is a configurable variable in Defaults.py that allows the site admin to decide whether or not to do "smart address matching" - where scott@chronis.pobox.com matches scott@pobox.com as the same address (these addresses are in reality different addresses ;). A listing of the changes to the files follows: Defaults.py.in - added SMART_ADDRESS_MATCH variable and a short description, defaulting to 1. MailCommanHandler: removed string.lower(address) in processSubscribeCmd and replaced it with Utils.LCDomain(address) MailList.py: made AddMember and ApprovedAddMember use Utils.LCDomain(address) instead of string.lower(address) Utils.py: got rid of top level domain listing and commented out corresponding code in ValidEmail since it seems clear that we have no intention of using this anymore. added LCDomain(address) which lowercases only the domain part of an address if there is a domain part. made AddressesMatch use LCDomain instead of string.lower, made it check LCDomain(addr1) == LCDomain(addr2) if mm_cfg.SMART_ADDRESS_MATCH is set to 0, and do the match it used to do if that variable is set to 1. scott
* These changing are a cleanup of the sorry state the subscription policycotton1998-10-101-81/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | was in (which was largely my fault from before). Before: 1) web_subscribe_requires_confirmation was showing in the admin cgi, but not working. 2) all subscribes that required admin approval were going through the confirmation process. 3) the code implementing the confirmation process was distributed between the subscribe cgi and MailCommandHandler, duplicated in places and disrupting the previous interface to list.AddMember. 4) the open_subscribe variable was confusing because it didn't pay any attention to confirmations. Now, things are organized a little differently, but in a much cleaner way. there is one variable that deals with subscription policy, called "subscribe_policy". It's setting determines what happens with both the web based and the mail based subscriptions. there are 4 options: 0 - open subscribe policy 1 - confirmation required 2 - admin approval required 3 - confirmation and then admin approval required there is a site configuration variable in Defaults.py called ALLOW_OPEN_SUBSCRIBE, which determines whether or not an open subscribe policy is an option. If it's not, the admin cgi interface does not present it as an option. I have restored a slightly modified version of the prior-to-confirmations interface for list.AddMember, where all you have to code is: try: list.AddMember(email, digest, password) except Errors.MMBadEmail: except Errors.MMAlreadySubscribed: [ ... all those other good things it used to check ...] except Errors.MMSubscribeNeedsConfirmation: # the confirmation has already been sent. # so just report accordingly to whatever the ap is. In addition, I have moved the code for processing a confirmation request to MailList.py so that it can be used in both a confirmation cgi (which does not yet exist, but will) and the mailcmd script. it's interface is: try: list.ProcessConfirmation(cookie) except Errors.MMBadConfirmation: # the cookie doesn't correspond to anything except Errors.MMNeedApproval: # the list is set to approve+confirm subscribe_policy. A listing of the changes to the files follows: Mailman/Defaults.in: added ALLOW_OPEN_SUBSCRIBE,DEFAULT_SUBSCRIBE_POLICY deleted DEFAULT_OPEN_SUBSCRIBE, changed DATA_FILE_VERSION to 5 Mailman/Errors.py: added MMBadConfirmation and MMSubscribeNeedsConfirmation Mailman/MailCommandHandler.py: moved the confirmation code to MailList.py and use the new (old) list.AddMember interface MailMan/MailList.py: added .ProcessConfirmation(cookie), changed AddMember to fit new (old) interface. deleted config info for open_subscribe and replaced with config info for subscribe_policy that acts according to mm_cfg.ALLOW_OPEN_SUBSCRIBE. Also made list.ApprovedAddMember's "noack" argument just "ack" for simplicities sake and made it default to None instead of 0 so that if the ack variable isn't passed, it sets it to the value of the lists .send_welcome_msg setting. Mailman/versions.py: added handling for new data file format, replacing open_subscribe with a reasonable value for subscribe_policy based on a combination of what open_subscribe is and what mm_cfg.ALLOW_OPEN_SUBSCRIBE is set to. Mailman/Cgi/admin.py: made the cgi handle the output and processing of subscribe_policy based on the setting of mm_cfg.ALLOW_OPEN_SUBSCRIBE. removed erroneous processing of whether or not to send an ack with mass subscription based on new interface to list.ApprovedAddMember (this processing is to be replaced with a good idea from john -- making mass subscribe have it's own option of whether or not to send welcome messages). Mailman/Cgi/subscribe.py: made backgrounds white, and made it use the MailList.AddMember interface described above. Mailman/Makefile.in: looks like this part of that distclean patch from NAGY didn't make it in yet (rm'ing mm_cfg.py as well as Defaults.py) scott
* Nagy's mail command end patch (add "--" as equivalent to "end" commandcotton1998-10-091-1/+1
| | | | | to stop processing of .sigs scott
* ProcessSubscribeCmd(): Deny attempts to subscribe a list to itselfklm1998-09-051-1/+9
| | | | | - and log a message in the new log file, "mischief" indicating the error and, if available, the identity of the host where it originated.
* Respect default limit on number of mail command lines for processing.klm1998-09-031-5/+10
| | | | | | (Large, misdirected mail commands can lead to near-thrash conditions, while the MailCommandHandler slogs through misguidedly trying to process too many lines...)
* .ProcessSubscribeCmd(): Using .FinishSubscribe(), which handles allklm1998-07-131-37/+47
| | | | | | | | | | | | | | | | | the constraints. (It looks like .FinishSubscribe() was made for this purpose, but not used anywhere! Perhaps it was used but someone inadvertantly switched away from it. I changed the location of the definitions to reflect .FinishSubscribe()'s subordinate role. Also, adapted to new version of verify.txt. .FinishSubscribe(): added option for running AddApprovedMember, so this routine can be used for both kinds of Add*Member. Also, fixed crashing NameError reference in MMNeedApproval case. Also, logging error details in case where unrecognized disposition exception is encountered. Added docstrings to help distinguish the relationship of .ProcessSubscribeCmd() and .ProcessConfirmCmd()
* .ParseMailCommands(): Escape the list real_name that's interpolatedklm1998-07-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | into the confimation-expression pattern, to prevent regex-significant characters in maillist names from tripping-up the regex compiler. This really can happen - in fact, it does when people try to subscribe to the "c++-sig"! (I've cursorily checked through the python stuff in scripts, Mailman, and Mailman/Cgi for other interpolations that might trip re.compile, but didn't find any other instances. Be on the lookout, though, this is a tricky one...) (This was present in 1.0b4, as well, and i believe it accounts for two elusive, outstanding problems: - the "pcre.error : ('nothing to repeat', 2)" traceback, which i mentioned on my recent "problems" list, and - reports i've gotten (one this morning, coincidentally) of failures in subscribing to c++-sig.) I'm going to deliver a patch for 1.0b4 to the newsgroup, once i track down a few other problems.)
* Prevent processing of exactly duplicated commands. This isklm1998-07-121-3/+18
| | | | | | | particularly to avoid the inevitable duplication in the subject and body, common for other mlm's, where people forget whether it's the subject or the body that has effect. In mailman, it's both - but now, not for duplicates.
* Informatively reject mail-command attempts to subscribeklm1998-07-121-3/+8
| | | | | | | | | | | | | | | | | | | already-subscribed members. (The prior checkin was for web-based subscription attempts.) NOTE that both these already-subscribed actions can constitute privacy leaks - someone could venture subscription attempts with addresses which they are trying to test for already-existing membership - and this response will provide unequivocal confirmation in the cases when the addresses are subscribed. One possible remedy is to send the refusal to the address being subscribed. This way the person taking the action gets no additional info unless they have access to the subscribees email channel. Problem with this is that it complicates the mail-command refusal process substantially, since it's currently geared, very simply, to send the refusal to the requesting address. Do we think the privacy leak is important enough to fill this hole?
* ProcessSubscribeCmd(): Fixed a few of the other keys :-(bwarsaw1998-07-061-2/+2
|
* MailCommandHandler.AddApprovalMsg(): use the Utils.maketext()bwarsaw1998-06-231-18/+11
| | | | | | | | | | | interface. MailCommandHandler.ProcessConfirmCmd(): Near the bottom of the method, where self.AddRequest() is called on a closed list, wrap the call in a try/except so as to catch the MMNeedApproval exception that gets raised. John, please verify that I'm doing this right.
* Convert all module names to their new names.bwarsaw1998-06-191-145/+70
| | | | | | | Removed RCS crud Help text moved into templates/*.txt file, but there are still a few TQS's to convert left.
* Whoops, I forgot to check these in. They're changed to handleviega1998-06-031-3/+3
| | | | | relative paths, mainly GetScriptURL->the appropriate replacement. Now I'm done w/ checkins, and I'm going to test the current snapshot.
* Hmm, I didn't think I touched mm_pending since the last checkin. Iviega1998-05-301-2/+4
| | | | | | | | dunno what changed there. In mm_mailcmd, I fixed a bug w/ Scott's code, so that if a reply comes back with no body, the confirm still works. I don't know why he was checking the body and not just the header for the pattern, but I left that check in there in case he had a good reason.
* Integrated Scott's confirmation stuff into mailcmd, and fixed a few thingsviega1998-05-291-41/+95
| | | | in pending...
* Fixed a typo in the zipcode.viega1998-05-261-2/+2
|
* 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?)
* Include a few more likely prospects among invalid request senders.klm1998-04-281-2/+2
|
* Discard "mail commands" from postmaster accounts (nobody,klm1998-04-271-5/+15
| | | | | | | | mailer-daemon, postmaster, orphanage, postoffic) - they're almost certainly delivery-failure notices. I'm going to poll the mailman-developers list for suggestions about refinements to this approach.
* Ignore any mailcommands coming from postmaster-type accounts -klm1998-04-231-1/+7
| | | | | | | | | mailer-daemon, postmaster, orphanage, and postoffice - on the presumption that they're failed subscribe instructions, bouncing back to the -request addr. I think this'll take care of that sticky problem fairly safely. Nobody should be sending commands from those accounts, anyway...
* Preparing to package a distribution - add __version__ info.mailman1998-04-091-1/+3
|
* Refined the 'info' mail command to indicate the list web page, presentklm1998-04-071-3/+13
| | | | the description a bit more tidily.
* Use new .DeleteMember() arg to indicate whence this deletion came.mailman1998-04-021-4/+4
| | | | Correct typo "succeded".
* Furthermore, mention the password-sending facility.klm1998-04-021-1/+4
|
* Mention the listinfo URL for the list in the mailcmd help message.klm1998-04-021-3/+10
|
* Send error notice back when we clearly have a list-specific command,klm1998-03-271-22/+45
| | | | | | | | | | like 'who', that is getting an alternate list-name as an argument, instructing sender to use the '-request' address for the list. (This way we can make 'majordomo@site' an alias to, eg, mailman-request@site, and get most of the majordomo@site behavior without implementing any exceptional behavior...) Add a module docstring, wrap a bunch of long lines.
* Swap order on digested and non-digested members, so longer listmailman1998-03-271-8/+13
| | | | (nondgested) is shown second
* Tracked change of names of 'closed' and 'auto_subscribe' options. Seemailman1998-03-241-6/+7
| | | | concurrent mm_defaults.py checkin for details.
* We're having a problem where mail command messages with undeliverablemailman1998-03-191-3/+5
| | | | | | | | "Sender:" lines are being bounced to the -request addr, and then being treated as a bad request. This needs to be examined and solved, but in the meanwhile i'm adding some info (the subject line) to the "subject line ignored" line, so we get some more cues to go on when things go awry.
generated by cgit v1.2.3-70-g09d2 (git 2.51.2) at 2025-11-09 15:01:09 +0000