Search results for "sapiro" - lists.mailman3.org

[MM3-users] Re: When mass subscribing using format John Doe <john.doe@example.com>, "Members" show some with real name, others without.

by Mark Sapiro

On 10/30/19 2:08 AM, Henrik Rasmussen wrote: > > It seems (I’m not certain about this) that the one’s without real name is the one’s already having an account and thus registred in Django (admin/auth/user/), while the ones subscribed with full name associated is the ones not having an account already. That's probably correct, but not the exact reason. > However, as soon as the member (the one with the account) went to Account and changed his real name, the name was immediately associated with the subscription in Members -> Subscribers. > > I expect this to be by design, but why isn’t the name associated with the subscription when mass subscribing in the first place, taken from the account? To understand, you need a bit of background. The basic engine that manages lists, subscriptions, users, etc. is Mailman core. Core does not provide any web UI. It only provides a REST API for use by other components. It is possible to run Mailman core only without any web UI, but management would need to be done directly via the REST API and/or `mailman shell` which is not particularly convenient. Because Mailman would not be too useful without a web management UI and a web based archiver, we provide Postorius and HyperKitty for these functions. These are only one possibility. One could build an entirely different web UI or other application to communicate with core via its REST API, but few if any have done so. Postorius and HyperKitty are Django projects and run under Django. The account that you see (Postorius top right) is a Django account. Core knows nothing about this. Core knows about users and addresses in its own database which is entirely separate from Django's accounts. These user/address records in core is where the user's display_name is kept. So when a user/address is added to a list, if core already knows that user/address, it just links that to the list and doesn't update the display_name, but if it doesn't know the user/address, it creates it and uses the supplies display name. It appears there is a mechanism within Postorius to detect a change in the name associated with a Django user and update core, but this is separate from subscribing. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 10 months

[MM3-users] Re: Clean-up of non-members

by Odhiambo Washington

On Mon, Dec 23, 2024 at 8:58 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 12/23/24 02:16, Odhiambo Washington via Mailman-users wrote: > > On Mon, Dec 23, 2024 at 1:37 AM Mark Sapiro <mark(a)msapiro.net> wrote: > > > >> Isn't this just `mailman members --role nonmember LISTSPEC`? > >> > > > > I didn't know that the option was right in front of me, but it seems > there > > is a problem: > > GNU Mailman 3.3.10 (Tom Sawyer), Mailman Core API Version 3.1 > ... ^^^^^^^^^^^^^^^^^^^^^^^^ > > AttributeError: 'NoneType' object has no attribute 'display_name' > > > I saw that too. Reported > https://gitlab.com/mailman/mailman/-/issues/1187 and fixed > https://gitlab.com/mailman/mailman/-/merge_requests/1297 It isn't clear to me what I should do to mitigate the error. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

8 months, 2 weeks

[MM3-users] Re: What to backup?

by Mark Sapiro

On 5/26/19 7:00 AM, Alain Kohli wrote: > I have noticed that especially the var/messages directory has a rather > considerable size compared to the rest. What exactly is this for and > what would be the consequences if that was lost? When a message is held for moderator approval, a pickle of the message is stored in the var/messages directory and an entry pointing to it is made in the message table in the database. An entry is also made in the list's pending requests. These are required so the held message can be handled. There is an issue in that when these messages are handled these aren't removed. See <https://gitlab.com/mailman/mailman/issues/257>. Thus, most of what's in the var/messages directory is old, but there are also currently held messages there that would be lost. You could periodically remove older messages, but this would leave entries pointing to them in the message table in the database which could cause errors but probably not. The real solution is a fix for <https://gitlab.com/mailman/mailman/issues/257>. > And more generally, would not backing up var/ at all only result in the > loss of some short term data (e.g. messages that are held or currently > processed) or would long term data also be lost? Or in other words, what > exactly would be non-recoverable if that isn't backed up? That depends in part on what your backend database is. If it's SQLite, the database is probably in the var/data directory. If not, you need to be backing up the MySQL or postgreSQL mailman database. var/archives contains archived messages for the 'prototype' archiver and messages that are queued for hyperkitty. var/cache contains a cache of recently used templates. var/data may contain a SQLite database and may contain Postfix mappings. The Postfix mappings can be regenerated by the `mailman aliases` command. var/etc may contain your mailman.cfg if you don't point to a different one. var/lists contains accumulated messages for the next digest for your lists var/locks contains locks and should probably not be restored from a backup var/logs contains Mailman's logs. var/messages is discussed above. var/queue contains Mailman's current queues. Except for 'shunt' this is all things currently in process. var/templates may contain custom templates. Also, I didn't mention it before, but your Django settings.py and settings_local.py should also be backed up. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 3 months

[MM3-users] Re: New Mailman 3 installation issues

by Mark Sapiro

On 5/18/21 12:30 PM, sarah.hartt(a)ionica.ca wrote: > I have been trying to get a mailman 3 installation working for longer than I'd like to admit. Core appears to be installed and working as desired but Postorius (and hyperkitty, but I haven't even started troubleshooting it while trying to get the web interface working) is only loading the main page with no lists shown and all remaining links return a server error (specific text is: "Server error > An error occurred while processing your request." with the error text highlighted). I think I followed all of the installation instructions, including the updated pythonpath line in the systemd module, but it's entirely possible that there is an error somewhere along the way. Is there more information in logs? (nginx and django) > I have had to make two minor tweaks, the /static/ location was moved from /opt/mailman/web/static to /var/www/mailman/ (owner mailman:nginx) as nginx was giving permissions errors (even if it owned the files or with the mod set to 777) with the default location and wouldn't load the css, and installed postgres directly from their repo as the method in the guide doesn't create the user. Aside from that everything should be exactly as laid out in the installation guide. The permissions is probably a SELinux or apparmor issue. Which installation guide are you following? I'm guessing https://docs.mailman3.org/en/latest/install/virtualenv.html. Are you saying that ``` sudo apt install postgresql ``` doesn't create a `postgres` user? It should. > The logs are showing everything running and the DB logs show all the queries going through successfully, there are no errors in the web logs corresponding with the errors being served on the site aside an entry for a 500 in the access logs > > [18/May/2021:12:13:01] "GET /archives/ HTTP/1.1" 500 1102 "http://mailman3/mailman3/lists/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.91 Safari/537.36" "-" This is a GET of /archives/ which is HyperKitty. Django should log something for this with more detail. > when I took a look in the DB tables many of them appear to be empty, I have a few lists in core that were imported from 2.1 but no new lists created. Empty tables per se is not necessarily a problem depending on which ones. > Mailman: 3.3.4 > Postorius: 1.3.4 > OS: Oracle Linux 8.3 > Python: 3.6 > postgres: 13.2 -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 3 months

[MM3-users] Re: 500 error on Held Messages page

by Mark Sapiro

On 9/21/22 10:39, Dan Caballero wrote: > I figured out the correct import based on what was done previously. It worked. Why do you think you need to import anything? > ">>> from mailman.app.moderator import handle_message `handle_message` is not referenced in the following and doesn't need to be imported here. ``` >>>> requestdb = IListRequests(m) >>>> for req in requestdb.held_requests: > ... if req.request_type == RequestType.held_message: > ... if not requestdb.get_request(req.id): > ... print(f'Bad request id: {req.id}, deleting') > ... requestdb.delete_request(req.id) > ... > Bad request id: 1694, deleting > Bad request id: 2509, deleting > Bad request id: 2727, deleting > Bad request id: 3251, deleting > Bad request id: 3265, deleting > Bad request id: 3371, deleting > Bad request id: 4844, deleting > Bad request id: 6058, deleting > Bad request id: 6201, deleting > Bad request id: 6432, deleting > Bad request id: 6502, deleting >>>> commit ()" ``` I assume after doing this, you were able to access the held messages view for the list. Note that the only names referenced in the above and not defined there are `IListRequests` and `RequestType`, but these are among the many names implicitly imported by `mailman shell` in interactive mode. ``` $ mailman shell Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. >>> for name in dir(): ... print(name) ... ALL_TEMPLATES ALT_TEMPLATE_NAMES ALWAYS_REPLY AcceptEvent AcceptOwnerEvent Action AddressAlreadyLinkedError AddressError AddressNotLinkedError AddressVerificationEvent AlreadySubscribedError ArchivePolicy ArchiveRenderingMode BadDomainSpecificationError BounceContext ChainEvent ClobberDate ConfigurationUpdatedEvent ContinueProcessing DMARCMitigateAction DatabaseError DeliveryMode DeliveryStatus DigestFrequency DiscardEvent DiscardMessage DomainCreatedEvent DomainCreatingEvent DomainDeletedEvent DomainDeletingEvent DuplicateStyleError EmailError ExistingAddressError FilterAction FilterType HoldEvent IAPI IAcceptableAlias IAcceptableAliasSet IAddress IArchiver IAutoResponseRecord IAutoResponseSet IBan IBanManager IBounceEvent IBounceProcessor ICLISubCommand ICacheManager IChain IChainIterator IChainLink IConfiguration IContentFilter IDatabase IDatabaseFactory IDomain IDomainManager IEmailCommand IEmailResults IEmailValidator IHandler IHeaderMatch IHeaderMatchList ILanguage ILanguageManager IListArchiver IListArchiverSet IListManager IListRequests IMailTransportAgentAliases IMailTransportAgentDelivery IMailTransportAgentLifecycle IMailingList IMember IMembershipManager IMessage IMessageStore IMutableChain IOneLastDigest IPendable IPended IPendedKeyValue IPendings IPipeline IPlugin IPreferences IRoster IRule IRunner IStyle IStyleManager ISubscriptionManager ISubscriptionService ISwitchboard ITemplate ITemplateLoader ITemplateManager IUser IUserManager IWorkflowState IWorkflowStateManager InvalidConfigurationError InvalidEmailAddressError InvalidListNameError LinkAction ListAlreadyExistsError ListCreatedEvent ListCreatingEvent ListDeletedEvent ListDeletingEvent MailmanError MemberRole MembershipChangeEvent MembershipError MembershipIsBannedError MissingConfigurationFileError MissingPreferredAddressError MissingUserError NewsgroupModeration NoSuchListError NotAMemberError PasswordChangeEvent PendType Personalization RejectEvent RejectMessage ReplyToMunging RequestRecord RequestType Response ResponseAction RunnerCrashEvent RunnerInterrupt SomeRecipientsFailed SubscriptionConfirmationNeededEvent SubscriptionEvent SubscriptionInvitationNeededEvent SubscriptionMode SubscriptionPendingError SubscriptionPolicy TokenOwner TooManyMembersError UnrecognizedBounceDisposition UnsubscriptionConfirmationNeededEvent UnsubscriptionEvent UnverifiedAddressError __builtins__ abort commit config getUtility m >>> ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 11 months

[MM3-users] Re: Counter-intuitive header filter processing

by Mark Sapiro

On 09/18/2018 01:04 PM, Jonas Meurer wrote: > > Maybe then the description for chain "accept" in postorius needs to be > adjusted. Currently it says "Accept immediately (bypass other rules)". > This gives the impression, that it will overrule the default action. Yes, I agree it's confusing. > A related followup question: what configuration is recommended for an > announcement list where only specific senders (e.g. sender(a)example.org) > should be allowed to post and mail from all (other) subscribers should > be rejected? > > The only way I see to achieve this currently is: > > * Set default action for member posts to "Default processing" > * Add a header filter to accept "sender(a)example.org" > * Add a header filter to reject ".*" > > In my eyes, that's very counter-intuitive and cumbersome to configure. > But maybe I just missed a more obvious and elegant solution to achieve > the same? The way to do that is to set the default action for member posts to Reject and set Member Options -> Administration options -> Moderation for the authorized posters to Accept or Default processing as desired. However, this allows anyone to post by spoofing an authorized address. To avoid that, leave everyone's Moderation setting at List default and post using "pre-approval" (see <https://mailman.readthedocs.io/en/latest/src/mailman/rules/docs/approved.ht…>. The downside of this is it requires the poster to send a cleartext password in a header or body line of the post. It will be removed from the post delivered to list members, but sending it in cleartext in an email may be an issue. We will eventually do something with PGP signatures instead, but that isn't here yet. > And one more comment: if I make the list an "anonymous list" (i.e. "hide > the sender of a message, replacing it with the list address"), then > header filters for the "from" header don't work any longer. That's kind > of unexpected as well. I would have expected mailman to process the > header filters at reading the incoming mail, not after rewriting headers > of the outgoing mail? Your expectation is correct. All the applicable rules are applied to the incoming message before any message alterations such as anonymizing are applied. Possibly you were confused because some other rule's action took precedence over your header rule. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 11 months

[MM3-users] Re: [ERROR] Error handling request List archivers

by Mark Sapiro

On 7/23/20 12:39 AM, Shashikanth Komandoor wrote: > Thank you Mark for guiding me to the benefit of putting the list and so I > have added the list. > > Along with the [archiver.hyperkitty], [mta] and [database], few lines of my > mailman.cfg look like below: > > > > [webservice] > workers = 4 > timeout = 900 > > The above block of webservice is added yesterday for testing or trail as I > am getting the above issue. > > And there is no line that is calling *gunicorn* in my mailman.cfg. As I tried to explain to you in an off-list reply: You can't configure Mailman's REST gunicorn workers directly in the [webservice] section of mailman.cfg. The only thing you can configure there is: configuration: /path/to/gunicorn.cfg That file, which is separate from your web server gunicorn.cfg, is where you put things like [gunicorn] timeout = 900 It also will not work to put a gunicorn section in mailman.cfg. It must be in a separate file pointed to by webservice.configuration. Increasing the number of workers won't help this issue. > Apart from that I tried to locate and see the content of the gunicorn.cfg > file as below : > > *(venv3) [root@lsmgr mailman]# cat /var/lib/mailman/mailman/src/mailman/config/gunicorn.cfg > [gunicorn] > # All the options that can be put here are available at > # http://docs.gunicorn.org/en/stable/settings.html#settings > > # No of seconds to wait before killing the worker processes. > graceful_timeout = 30 > > Please confirm the time I have to change is *graceful_timeout *in > *gunicorn.cfg* and if I have changed how do I restart the *gunicorn*. I > have never used or never known about this *gunicorn* but still running the > service in production. First, the file you reference above is the default gunicorn configuration for the REST server. You don't want to edit this file because your changes will be overridden in an upgrade. You want to create your own gunicorn.cfg file and point to it by adding configuration: /path/to/your/gunicorn.cfg to the webservice section in your mailman.cfg. Your gonicorn.cfg does not need to contain the graceful_timeout = 30 setting as that is a gonicorn default, and that is not what you need to increase. What you need is [gunicorn] timeout = 900 (actually 900 seconds is probably way overkill. 90 seconds would probably be enough.) -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 1 month

[MM3-users] Re: Installing mailman 3

by Rafael Mora

Ok, I screwed the mailman install ..... I reinstalled mailman core. How do I do a Python2 virtualenv? Thanks El vie., 21 jul. 2017 a las 15:03, Mark Sapiro (<mark(a)msapiro.net>) escribió: > On 07/21/2017 12:44 PM, Rafael Mora wrote: > > I did this: > > > > (env) [mailman@localhost mailman-suite_project]$ pip install Django > > Requirement already satisfied: Django in > > /var/lib/mailman/env/lib/python3.6/site-packages > > Requirement already satisfied: pytz in > > /var/lib/mailman/env/lib/python3.6/site-packages (from Django) > > > > > > Does Django is already installed?? with python3.6 ??? > > > Your 'env' vitrualenv is a Python 3 virtualenv. You need this for > Mailman core, but Django and mailman-suite are Python 2. They need to be > installed and run in a Python 2 virtualenv. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- Atentamente / Best Regards Ing. Rafael Mora

8 years, 1 month

[MM3-users] Re: Hyperkitty 1.1.1 to HyperKitty 1.2.1

by Thomas G

I tried all job, without result. (and they are correctly in the crontab) [image: image.png] If I try to find my list in the form, hyperkitty can find it: [image: image.png] Le mer. 3 oct. 2018 à 17:59, Mark Sapiro <mark(a)msapiro.net> a écrit : > On 10/03/2018 02:30 AM, Thomas G wrote: > > > I have just a problem with statistics not available. > > > If cron is running all the periodic django jobs, this gets fixed > eventually. The one thing you may need to run manually is > > manage.py runjob thread_order_depth > > as that helps with some things and is a 'yearly' job. I think the > 'hourly' and 'daily' jobs fix most other issues. See > > manage.py runjob --list > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >

6 years, 11 months

[MM3-users] Re: member appears twice in list - how?

by Mark Sapiro

On 11/5/24 11:09, Jose Bernal via Mailman-users wrote: > I've got a list member showing up twice in a list (same email address). > Can't use the GUI to remove the member from this list (get a 503 error) > Screenshots attached, underlying database query reveals no duplicates. > Wondering how this is possible or where else I should be looking to resolve > this duplicate before I simply remove their entry from the members table > altogether. I'm not sure how this could have happened, I need more info for that, but to deal with this use `mailman shell` as in ``` $ mailman shell -l list(a)example.com Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the list(a)example.com mailing list >>> x = m.memberships('user(a)example.com') This should set x to a list of that users memberships You can then examine x[0] and x[1] to determine which to delete. e.g. >>> dir(x[0]) ['__abstract__', '__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getstate__', '__gt__', '__hash__', '__implemented__', '__init__', '__init_subclass__', '__le__', '__lt__', '__mapper__', '__module__', '__ne__', '__new__', '__providedBy__', '__provides__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__table__', '__tablename__', '__weakref__', '_address', '_lookup', '_mailing_list', '_member_id', '_reset', '_sa_class_manager', '_sa_instance_state', '_sa_registry', '_user', 'acknowledge_posts', 'address', 'address_id', 'bounce_score', 'delivery_mode', 'delivery_status', 'display_name', 'id', 'last_bounce_received', 'last_warning_sent', 'list_id', 'mailing_list', 'member_id', 'metadata', 'moderation_action', 'preferences', 'preferences_id', 'preferred_language', 'receive_list_copy', 'receive_own_postings', 'registry', 'role', 'subscriber', 'subscription_mode', 'total_warnings_sent', 'unsubscribe', 'user', 'user_id'] This gives the list of attributes which can be examined with, e.g. >>> x[0].delivery_mode <DeliveryMode.regular: 1> You can then remove the one you don't want, e.g. >>> x[0].unsubscribe() >>> commit() ``` Just to be sure, you should ensure that x[0].member_id and x[1].member_id are different. These are the _member_id column in the member table in the database. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

10 months, 1 week

Search results for query "sapiro"