Search results for "Postorius" - Mailman-users

Re: Digests not working correctly

by Joel Lord

On 6/4/2023 9:25 PM, Mark Sapiro wrote: > On 6/4/23 11:45, Joel Lord wrote: Thanks for the explanation on size-triggered digests. >> Periodic is much more complicated, even to explain. I have the cron >> job running nightly at 11:00 PM and it certainly seems to be working, >> except for one really odd thing. The list also definitely has >> periodic digests enabled in the web UI. This is a very bursty list, >> so it will go mad with traffic for a few weeks and then will go mostly >> idle for a month or so. The first digest of a burst is definitely >> size-triggered, but pretty reliably it has the last few messages from >> the previous burst in there. So the one I got today had three >> messages from today and one message from May 4th. But that May 4th >> message should have gone out at 11:00 PM on May 4th with the daily >> digest and then gotten flushed from the pending digest queue, right? > > That's correct. Do you ever get periodic digests sent at 11:00 PM? If > not, there is some issue either with configuration or something. If you > get them sometimes, I don't know what could be wrong. The periodic digests do seem to be coming out. I also now have confirmation that the one message in this morning's digest that was from May 4th was also included in the last digest back on May 4th, so it seems that the one message was left behind in the digest queue when the periodic digest was sent. There was one earlier message to the list back on May 4th, before the one that got duplicated, but I can't tell if that triggered a size-based digest to be sent: the logs aren't clear enough on that detail for me to tell. Just to inform things: (venv) lists@host2:~/mailman/venv/bin$ pip freeze | grep mailman django-mailman3==1.3.9 mailman==3.3.8 mailman-hyperkitty==1.2.1 mailman-web==0.0.6 mailmanclient==3.3.5 (venv) lists@host2:~/mailman/venv/bin$ pip freeze | grep hyper mailman-hyperkitty==1.2.1 (venv) lists@host2:~/mailman/venv/bin$ pip freeze | grep post postorius==1.3.8 -- Joel Lord

2 years, 3 months

Re: Filter who can send on mailman3 list?

by Ruth Ivimey-Cook

Marcus, I'm with you in not understanding Mark's instructions -- I think there is a typo somewhere :-) To create a non-member user in Mailman, Go to the List Settings page in Postorius, select Non-members from the User menu, and add a user there. Of course, that does nothing for your email system, which must also be configured. I would very strongly encourage you to have the no-reply address be 'real' in the sense that the email system will agree it is valid and deliverable, or some recipient email servers will refuse to accept email from that address, either. The right thing is for email to that address accepted as normal and then immediately discarded. You could send back a message "this address is not monitored" but there is an issue with spam backscattering which makes that less good than it first seems. Regards, Ruth On 06/04/2021 10:00, marcus.granath(a)gmail.com wrote: > Thank you @Mark Sapiro for you quick reply. > > So by doing the following settings, then ALL the messages sent to the list will be hold for moderation: > > Settings -> Message Acceptance > > "Default action to take when a member posts to the list": "Hold for moderation" > "Default action to take when a non-member posts to thelist": "Hold for moderation" > > Members -> Administration options -> Moderation: "List default" > > BUT I don't really follow you when you say that those 3 allowed users to send on the list should also have set to "Moderation: List default"? > How will they then be able to send messages, or what do I misunderstand here? > > Also, how do I create a "non-member" user "no-reply(a)abc.com"? > Do you mean that I do that under the "Mass operations -> Mass subscriptions" ? Can I add a "fake address" there? > _______________________________________________ > 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/ -- Software Manager & Engineer Tel: 01223 414180 Blog: http://www.ivimey.org/blog LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/

4 years, 5 months

Re: Unsubscribe Notifications to List Owners and Members

by Brian Carpenter

What list are you trying to unsubscribe from and how are you doing it? On 10/22/20 4:58 PM, Jerry Koutavas wrote: > > No offense but been trying to unsubscribe for months, nothing happens > > *From:*Brian Carpenter [mailto:brian_carpenter@emwd.com] > *Sent:* Thursday, October 22, 2020 4:56 PM > *To:* Mailman users <mailman-users(a)mailman3.org> > *Subject:* [MM3-users] Unsubscribe Notifications to List Owners and > Members > > It seems that the only time an unsubscribe notification is sent to a > list owner and/or list member is when a list member sends an email to > lisname-unsubscribe@listdomain <mailto:lisname-unsubscribe@listdomain> > and that list member is not registered > with Affinity/Postorius. Can anyone confirm this and if confirmed, is > this considered a bug? > > > > -- > Brian Carpenter > Harmonylists.com > Emwd.com > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > <mailto:mailman-users@mailman3.org> > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > <mailto:mailman-users-leave@mailman3.org> > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > > ------------------------------------------------------------------------ > > *Total Control Panel* > > > > Login <https://asp.reflexion.net/login?domain=ascii.com> > > To: jk(a)ascii.com > <https://asp.reflexion.net/address-properties?aID=10188568&domain=ascii.com> > > From: mailman-users-bounces+jk=ascii.com(a)mailman3.org > <mailto:mailman-users-bounces+jk=ascii.com@mailman3.org> > > > > Message Score: 70 > > > > High (60): Fail > > My Spam Blocking Level: Medium > > > > Medium (75): Pass > > > > > Low (90): Pass > > Block > <https://asp.reflexion.net/FooterAction?ver=3&bl-sender-address=1&hID=458079…> > this sender / Block > <https://asp.reflexion.net/FooterAction?ver=3&ent=1&bl-sender-address=1&hID=…> > this sender enterprise-wide > > > > Block > <https://asp.reflexion.net/FooterAction?ver=3&bl-sender-domain=1&hID=4580794…> > mailman3.org / Block > <https://asp.reflexion.net/FooterAction?ver=3&ent=1&bl-sender-domain=1&hID=4…> > mailman3.org enterprise-wide > > > > /This message was delivered because the content filter score did not > exceed your filter level./ > -- Brian Carpenter Harmonylists.com Emwd.com

4 years, 10 months

Re: Newbie hyperkitty question

by Mark Sapiro

On 1/11/22 8:27 AM, Stephen Daniel wrote: > Mailman users -- > > I am setting up a new mailman3 installation, and this is my first > experience with the suite. All of the software is up and running, but I > cannot tell if hyperkitty is actually running. In Postorius, in the list's `info` view can you click the Archives button and see archived messages? That's HyperKitty. If the messages aren't there with the hyperkitty archiving option enabled, check `mailman.log` for why. Also do messages from the list have an Archived-At: header? > When I look at my test mailing list, two archive options are available, > hyperkitty and "prototype", and both are enabled. I can see that my email > is being archived, but I think "prototype" is what is doing the archiving. > I see that a test message will end up in > /opt/mailman/mm/var/archives/prototype/<LISTNAME>@<LISTDOMAIN.org>/new/164.... > and nowhere else. This suggests that "prototype" is archiving, but > hyperkitty is not. No this says the prototype archiver is working. It says nothing about Hyperkitty. > So, this opens up a raft of questions on hyperkitty: David Newman has answered some of this, but ... > - How do I tell if hyperkitty is actually running? It doesn't actually run. it is a Django web UI and a web API that serves things on request. > - Does hyperkitty have a web-UI for admins or users? How would I access > it? See above. > - I can not find any documentation on hyperkitty, other than > installation instructions and change logs. Does documentation exist? No, not really. > - How do I set policies on how long archives are kept? > - Assuming I want to back up my archives, what do I need to back up? Messages are kept forever unless you do something to delete them. HyperKitty's messages are stored in the database configured in the DATABASES setting in your Django settings. How you backup the database depends on the database manager. You already found the prototype archiver's messages. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 8 months

Re: How to store additional information about lists?

by Andreas Barth

* Stephen J. Turnbull (turnbull.stephen.fw(a)u.tsukuba.ac.jp) [210523 02:41]: > Andreas Barth writes: > > > Currently it is "list public" vs "subscribers only". I need something > > inbetween, so that some (i.e. most) people have access to the > > restricted audience lists but not just everybody. > > That much is clear. The problem is that "access to list" can mean a > lot of things: can subscribe, can post, can admin, can view archives, > can view list in listinfo, can view subscriber list, and there are > probably others. What permissions are needed for what general classes > of users? public: anyone can subscribe and read the archive. Think about an announcement mailing list of an organisation. restricted: for employees (or members - or whatever) only. So they could subscribe themself. The archive and posting may be restricted to subscribers or to anyone in that group - both would be working for me. (How to know who is allowed to subscribe is another question - having an internal mailing list which contains all the members just for this purpose would be ok for me.) private: hand-selected people, think about e.g. board or steering committees internal discussions. Of course, the archive (if there is any) should be restricted to the actual members. Posting to these lists is currently not restricted, so no derivation needed from the current set in postorius. > > Just as an idea, how about always one "custom attributes" field. So > > that from a database pov this field is always there. > > We could do that, but then we'd have to support it. I'm thinking of > situations like admin A populates the field, then leaves the > organization, and we add (some of) the supported features, and admin B > wants to migrate that. I don't see any good coming of that for us. > As Mark says, a separate table seems like the way to go for custom > attributes. Well, that problem will always exist. I don't think you would make it harder by having one "custom attributes" field. I'm going to try the plugin route Mark suggested. Andi

4 years, 3 months

Re: [MM3-users off list] Re: Welcome message template errors

by Mark

>> So, I'm thinking (in broad brush strokes) that if I'm stuck with this >> "http glitch" I could write a script to: >> >> 1. extract the text of the custom message from the database, >> 2. write that message text to a file >> 3. update the templates.uri entries to replace the >> http://localhost... with file:///path/to/file >> 4. cron the script to run every few minutes. >> >> It screams of utter clunk I know... > but it would work. > > Note that this may not be as big an issue as it seems. It doesn't > affect all templates, for example list:member:digest:footer, > list:member:digest:header, list:member:digest:masthead, > list:member:regular:footer, list:member:regular:header and > list:member:generic:footer are only used by the `out` runner when > sending messages, so these aren't affected. Right. Affected are all the "list:user:notice:***" (eg. goodbye, hold, reject,...) > > I'm still trying to determine what the issue is. To this end can you > tell me what Python version your Mailman uses and what is the output > from `pip freeze` with your venv active? $ mailman info GNU Mailman 3.3.9 (Tom Sawyer) Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] $ pip freeze aiosmtpd==1.4.4.post2 alembic==1.13.1 arrow==1.3.0 asgiref==3.7.2 atpublic==4.0 attrs==23.2.0 authheaders==0.16.2 authres==1.2.0 blessed==1.20.0 certifi==2023.11.17 cffi==1.16.0 charset-normalizer==3.3.2 click==8.1.7 cmarkgfm==2024.1.14 cryptography==42.0.1 defusedxml==0.7.1 Django==4.2.11 django-allauth==0.60.1 django-appconf==1.0.6 django-compressor==4.4 django-extensions==3.2.3 django-gravatar2==1.4.4 django-haystack==3.2.1 django-mailman3==1.3.12 django-picklefield==3.1 django-q==1.3.9 djangorestframework==3.14.0 dkimpy==1.1.5 dnspython==2.5.0 docutils==0.20.1 falcon==3.1.3 filelock==3.13.1 flufl.bounce==4.0 flufl.i18n==5.0.2 flufl.lock==8.0.2 greenlet==3.0.3 gunicorn==21.2.0 HyperKitty==1.3.9 idna==3.6 lazr.config==3.0 lazr.delegates==2.1.0 mailman==3.3.9 mailman-hyperkitty==1.2.1 mailman-web==0.0.9 mailmanclient==3.3.5 Mako==1.3.0 MarkupSafe==2.1.4 mistune==3.0.2 networkx==3.2.1 nh3==0.2.15 oauthlib==3.2.2 packaging==23.2 passlib==1.7.4 postorius==1.3.10 psutil==5.9.8 psycopg2-binary==2.9.9 publicsuffix2==2.20191221 pycparser==2.21 Pygments==2.17.2 PyJWT==2.8.0 python-dateutil==2.8.2 python3-openid==3.2.0 pytz==2023.3.post1 rcssmin==1.1.1 readme-renderer==42.0 redis==3.5.3 requests==2.31.0 requests-oauthlib==1.3.1 rjsmin==1.2.1 robot-detection==0.4 six==1.16.0 SQLAlchemy==2.0.25 sqlparse==0.4.4 types-python-dateutil==2.8.19.20240106 typing_extensions==4.9.0 urllib3==2.1.0 wcwidth==0.2.13 Whoosh==2.7.4 xapian @ file:///opt/mailman/xapian-1.4.24-cp311-cp311-linux_aarch64.whl xapian-haystack==3.1.0 zope.component==6.0 zope.configuration==5.0 zope.event==5.0 zope.hookable==6.0 zope.i18nmessageid==6.1.0 zope.interface==6.1 zope.schema==7.0.1

1 year, 4 months

Re: converting bulk accept_these_nonmembers in migration from mailman 2 to 3

by Lucio Chiappetti

Dear Mark, thanks for your interest. On Fri, 11 Feb 2022, Mark Sapiro wrote: > This may actually be a bug. I'll have to think about that. I've filed > https://gitlab.com/mailman/mailman/-/issues/978 on this. > This is https://gitlab.com/mailman/mailman/-/issues/794 (still open) Given the time needed to solve the issues (I will anyhow notify the site administrators, hopting they would update mailman when/if resolved), this means we have to find a workaround. > And those non-members all have there moderation action set to Defer > which means their posts will be accepted but the additional checks such > as too big, etc. will still be applied. not sure what you mean by "defer". The non-member options I see are called List default -- follow the list's default member action. Hold -- This holds the message for approval by the list moderators. Reject -- this automatically rejects the message by sending a bounce notice to the post's author. The text of the bounce notice can be configured by you. Discard -- this simply discards the message, with no notice sent to the post's author. Accept -- accepts any postings without any further checks. Default Processing -- run additional checks and accept the message. > If they are nonmembers, you can accept the post and set moderation > action in one operation in Postorius, but the regexps in > hold_these_nonmembers will still take precedence. OK, I've found where to do it, it requires to select the held message and scroll to the bottom then set Moderation from a menu. But if hold_these_nonmembers takes priority this will be uselesws in the current setting. > I'm not sure what you are looking at here. Imported nonmembers should > all have moderation action set according to which *_these_nonmembers > they came from. Imported members should have their moderation action set > to Defer if they were unmoderated and if they were moderated, it should > be set based on the 2.1 list's member_moderation_action. I go to the non-member list, select non-member options and at the bottom see an item Administration options Moderation. The possible values are those I pasted above. The actual value for most of the imported non-members is "Default processing" while it is "List default" for thoase automatically added afresh, It is "Discard" for a number of imported non-members with spam-looking addresses (I guess they were in some other *_not_members part of the standard 2.1 antispam ... I can't recall me doing something on those) Side question: is there a way to operate IN BULK on non-members ? Like it is for members (I exported them to CSV). >> - if so, how can we do it automatically for all 189 entries ? >> - or move back the 189 addresses to accept_these_nonmembers ? > Yes, move them back. I am not so concerned of these 189 (or better of the 189 minus the discard ones which should stay) ... anyhow moving them back will be uncomfortable if there is not a bulk operation tool. I am more concerned of the new cases automatically added. Our member list includes 1043 addresses. Of these less than 20 use an external address (say gmail), so they post "from home" and will pass. 194 addresses are of the form name.surname(a)inaf.it (these are likely to be recently hired staff, who have and use onlyu the organization-wide address). All the rest (so still more than 800, can't really ask all of them to re-register (*)) are of the form username(a)institute.inaf.it (and it won't be easy also to bulk-delete and bulk-resubscribe because of the inhomogeneous mapping of username to name.surname. Of these about 800 some are lurkers and are no problem. Some are frequent posters and remember to post from username(a)institute.inaf.it and are no problem. Other may post from an alternate address (maybe even the old address exists as a receiving-only alias), and in this case with the current arrangement they will bo on hold every time. I guess we should wait for the solution of issue 794 (*) by the way do you confirm that if one is subscribed to a list with an address (be it bulk subscription, import or new fast subscription), this person CANNOT change their settings (or address) unless one does a "sign in" to a (Postorius) account ? > It is because all the legacy *_these_nonmember actions are applied > before nonmember moderation checks, so if an address matches a regex in > hold_these_nonmembers, the post will be held regardless of the > nonmember's moderation action. > Addresses still work, and accept_these_nonmembers takes precedence over > hold_these_nonmembers just as in MM 2.1. This was not my impression when I ran a thorough test of 12 cases. Except the obvious case of the subscriber posting from the subscription address, all messages went on hold. Whatever the non-member moderation would be (even if set to reject ! ... but that makes sense if *_these_nonmembers prevail on non-member options), and even if the address was set explicitly in accept_these_nonmembers (should I delete it from the non-member list ?) What is the actual order (or flow chart) of choices ? *_these_nonmembers in the order listed in the page (within each in the order of occurrence of regexp's) then non-member options ? If I have Name.Surname(a)inaf.it in accept_these_nonmembers, then hold_these_nonmembers set to ^.+@.+\.it ^.+@.+\.tng\.iac\.es what do you foresee ? And for different regexps, will processing terminate at the first non-matching one, will they be ANDed or ORed, or what ? I am reluctant to accept inconditionally ^.+\..+(a)inaf\.it (they may be falsified, only the check on their presence in the other list (issue 794) I guess I should remove the ^.+@.+\.it regexp AND AT THE SAME TIME change the Default action to take when a non-member posts to the list to Hold instead of Discard. This way we'll have to check spam (instead of having it auto-discarded), but if people with alternate addresses post, once they are entered in the Non-member list they can be authorized to pass for the future ... .. would it work ? -- Lucio Chiappetti - INAF/IASF - via Corti 12 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html

3 years, 7 months

Re: Mailman, etc. upgrade woes and persistent bugs

by Abhilash Raj

I am trying to distill some information from this discussion to be used for the implementation in Postorius. I'll maybe reiterate a bit of what Steve was saying just to confirm I am on the same page. On Tue, Feb 16, 2021, at 7:23 AM, Stephen J. Turnbull wrote: > No answer required, I think I understand the situation pretty well > now. But if I'm missing something, I would very much appreciate > criticism. > > Andreas Barth writes: > > > Well, currently these are exclusive-states, I'd rather see them as > > or-able-states. > > Right, I understand that. I don't understand *why*. > > There are real costs to making them or-able. There are constraints: > 'enabled' shouldn't (mustn't?) be or-able with any 'disabled-by-foo' > state. Such invariants are finicky to code and tricky to maintain, > compared to a simple "mutually exclusive". > > I guess you want to allow the or of any subset of disabled states, but > presumably then they need to individually resettable in order for the > admin to clear their disable without overriding a subscriber's > preference or a bounce record. That set of controls is more complex, > and requires additional mental effort on the part of anyone using > them. If there are restrictions on which states can be or-ed, that's > more coding and maintenance cost. > > Then there's the question whether the subscriber can override the admin's > setting. If they can, why does the admin have this power in the first > place? > > > > > - "disabled by member" (could be set by an admin as well of course) > > > > > > Currently this is determined by whether the logged in user is the > > > subscriber or not. It's an interesting idea to allow it to be set by > > > an admin. Then we could have the semantics that the only transition > > > allowed from this state would be to enabled, so that admins would know > > > the user had intentionally disabled and know not to enable without > > > permission. > > > > Exactly. > > But if the admin should respect the DBS (disabled by subscriber) > setting, DBS|DBA (disabled by admin) is logically equivalent to DBS. > Are there use cases where the admin does not want to repect the > subscriber's choice, and enables it anyway? What are they? > > > Or while importing from another server, and there are people who > > have receiving mails disabled, this is the state that could be used > > for it. > > Why wouldn't they get the exact state from the original server? Or do > you mean from a non-Mailman server? > > > I expect that state to be the most-often used when setting a state > > manually. > > > > For "who set that", I would consider having some kind of history as > > useful (and displaying "last set by user / $person" to the admin but > > not the user). > > Why not to the subscriber? As I explain below, the subscriber at > least needs to be able to distinguish between DBA and DBB (disabled by > bounce). > > Keeping history of who is additional complexity, consumes a minor > amount of resources, and is insufficient to the purpose. Assuming > that there are reasons for admins to disable/enable other than as a > courtesy to a subscriber, that reason is presumably important. Not only > will the subscriber not know, but one admin may forget, and there may be > multiple admins.[1] > > I still don't see any reason for an admin to disable delivery other > than as a courtesy to the subscriber or to the bounce processor. > > > > > - "disabled for administrative reasons" (only by admin but user > > > > should be able to see it) > > > > > > I don't see why a user would need to see the difference. Unless > > > you're suggesting that the user would not be able to reenable without > > > asking the admin? What is the use case for this? > > > > I'm suggesting exactly that, yes. Why? Well, worked with user for too > > long. ;) > > > > E.g. consider that seeing archives works only for subscribers. And the > > subscriber in question complains about too many mails but still > > re-enables getting mails. This is basically "an admin has blocked you > > from more mails but not unsubscribed you". Might be an corner case, > > but still. Might also be too unimportant. > > This is possible. If it occurs less than once in a million years, > it's "too unimportant" to even think about.[2] Have you actually done > this, or know anybody who has? > > Is it really different from "at request of subscriber"? Practically, > the only difference I can see is if such a subscriber should be > prevented from overriding DBA. Are you suggesting that? > > > > > - "bounced" (user and admin could reset it but not set it) > > > > > > Reenable but not set "bounced" is the current situation. > > > > Except if someone sets the state to "disabled" and then undo this, the > > state is automatically cleared. > > This is possible, but it's not clear what harm would be done. In most > cases, bounces are intermittent and clear themselves up, in which case > this is the right thing. But if the subscriber bounces again, they'll > get disabled again, only cost is a slight waste of resources. > > Here's how I would assess the issues. In the descriptions below, I am > assuming that each state is the only "active" state. > > 1. DBS is probably a "vacation" or "post-only" setting. For that > reason it should be re-enabled only by the subscriber (or by an > admin at the request of the subscriber). > 2. DBB is a "warning" and a minor convenience to the email system > (slightly reducing traffic to mailboxes that are expected to fail, > and perhaps avoiding some reputational damage to the list). > Re-enabling much of the time causes no damage, as bounce disables > are typically due to things like out of disk space, and are likely > fixed by the time the subscription is reenabled. Most of the rest > will be zombie mailboxes, which will rarely be reenabled, will > quickly be redisabled by bounce, and at worst cause mild > inconvenience. Finally, events like a Mailman upgrade and the > April 2014 DMARC fiasco will be pretty evident, and the damage > there has already been done, reenabling actually fixes it > (although it may not be effective if the systemic problem hasn't > been resolved). > 3. DBA is interesting mostly to *subscribers*, who need to > distinguish DBA (which the subscriber can reenable freely) from > DBB (which warns the subscriber to get in touch with their > postmaster). It's comforting to subscribers who may be sure they > never disabled their subscription; otherwise, it's semantically > identical to DBS as far as I can see. > > Am I missing something? > > It seems to me that given 1-3, assuming a 4-state design: > > 0. It's never unreasonable to re-enable, except DBS. > 1. In the DBA state, changing to either DBS or DBB causes no > problems. (Changing to DBB is unlikely, since no mail is being > sent. However, it's possible, due to the race between Postorius > and mail in transit, and due to spam and other spoofing of the > list domain.) > 2. In either of the other two states, we should never change to DBA. > 3. In either of the other two states, if the other event occurs, you > would want the state to be DBS|DBB. I contend that if we > substitute DBS, little harm is done. If the subscriber reenables, it's > on them to fix the bounce problem if it reoccurs in any case. > Since the subscriber has deliberately set DBS, the admin should not > reenable without permission of the subscriber (I think we're mostly in > agreement on that). > > I think this 4-state design is much easier to design, validate, and > maintain than the 16-state design you propose. If you're really > worried about DBS|DBB, then we could have a 5-state design where > enabling from DBS|DBB generates a warning that there may still be a > bounce problem on the subscription. Instead, it could leave the > subscription in state DBB, but that seems to me to be obnoxious, since > there's little likelihood of harm from reenabling, and in many cases > the bounce problem will have resolved itself in the meantime. > So it seems like we have some sort of agreement that we need all the roles to be able to see all the 4 states. Roles here are basically Admin( i.e. list owner/moderator/site admin) and Subscriber. There is no access control to transition "from" any state but each value of non-enabled states is sort of a role's way to disable the delivery. Not all states are settable by all roles. 1. A subscriber can only transition from any to "enabled" or "by_user" state but can see if delivery was disabled "by_admin" or "by_bounces" as separate state in the Options page. 2. An admin can transition to "enabled", "by_user" and "by_moderator". They should use "by_user" when acting on behalf of the user and other when there are any administrative reason to disable delivery, whatever that may be. I expect "by_admin" to be used sparingly, and I don't see any use cases for it. 3. Mailman itself will use the "by_bounces" to disable delivery due to bounces. Is that an accurate description? -- thanks, Abhilash Raj (maxking)

4 years, 6 months

Templates branch for Mailman 3.1

by Barry Warsaw

Hello developers! There are three big features still in progress for Mailman 3.1, the templates branch, MySQL support, and unsubscription workflow. There is already a merge request for MySQL support and I'm hoping to merge that soon. Abhilash is also working on the unsubscription workflow feature but there's no MR for that yet. The templates feature is very nearly done, so I think now is a good time to ask for testing, feedback, and review. This is a generalization of the welcome_message_uri feature in MM3.0 where you could specify e.g. the welcome message as a URL to download and cache when necessary. This is important because Core doesn't know whether there is even a web ui (e.g. Postorius) involved, or where things like clickable links to unsubscribe would be. Sites also want to customize footers to include information like codes of conduct, etc. Now (or when this branch lands), you will be able to specify a URL to retrieve any template that Mailman uses internally, whether they are confirmation messages, bounce probes, welcome and goodbye messages, etc. These can be templates for administrators, users, and members. Because I'm hoping to get some reviews, I'll point you at the documentation for more details: https://gitlab.com/warsaw/mailman/blob/templates/src/mailman/rest/docs/temp… The branch did end up being much bigger and tentacled than I expected, but it's all hanging together pretty well now, and all the tests pass. There's still a small number of to-dos, but some of them will get punted, and the others won't have a major effect on the overall use and visibility of the feature. https://gitlab.com/warsaw/mailman/blob/templates/TODO.rst Note also that if you interact with the REST API v3.0, nothing changes externally, but the old IMailingList attributes are mapped onto the new templates mechanism. API v3.1 is where you see all the actual new feature end-points exposed. Of course, any MM2 list converted to MM3.1 will use the new templates stuff too. Feedback very much welcome, either here or on the MR: https://gitlab.com/mailman/mailman/merge_requests/170 I'd like to land this some time in the next week or so. Then I'll work on the other two big branches and start to release some betas. Cheers, -Barry

9 years, 2 months

Re: Problems after update to mailman 3.3.7

by Danil Smirnov

Hi Guillermo, We've faced the same issue and already reported it: https://gitlab.com/mailman/mailman/-/issues/1044 I would not recommend anyone using MySQL/MariaDB database engine upgrade to the latest version yet. With my best regards, Danil Smirnov Mailman3.com On Tue, Dec 6, 2022 at 4:32 PM Guillermo Hernandez (Oldno7) via Mailman-users <mailman-users(a)mailman3.org> wrote: > I've getting the most strange behaviour after update to last releases. > In one of my mailman3 servers, the messages doesnt reach for some lists > (the five last ones) > > the update have not showed any error but in the var/data for the lmtp > and vmap postfix files mailman does not create aliases for that last 5 > lists. Any message addressed to them is returned with a "no such user" > error. > > If I create a new list the system or restart mailman runners it shows > this error: > > Generating MTA alias maps > /usr/local/lib/python3.9/site-packages/pymysql/connections.py:799: > UserWarning: Previous unbuffered result was left incomplete > warnings.warn("Previous unbuffered result was left incomplete") > > I did a CHECK TABLE on mailinglists table but all seems ok. > > I tried reinstalling PyMySQL, but has no effect. (well, I tried > reinstalling all) > > It seems to me that something is preventing creation of that aliases, an > then the that last five lists are unreachable. > > I have no clue of what to do now and I'm driving crazy. > > Some direction to look for will be much apreciated. > > Thanks in advance. > > P.S.: I can access via postorius/hyperkitty to the archives of the lists > that are unreacheable. > > > -- > > ___________________________________________ > Mailman's content filtering has removed the > following MIME parts from this message. > > Content-Type: image/png > Name: firma-GHP-emails.png > > Replaced multipart/alternative part with first alternative. > _______________________________________________ > 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/ > Archived at: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to danil(a)smirnov.la >

2 years, 9 months

Mailman-users search results for query "Postorius"