Search results for "Postorius" - Mailman-users

Re: config incoming email in my domain cpanel

by Rafael Mora

Hello! Just to let you know, the problem with the email reception was that I was thinking that the email was coming from my hostgator panel, but I was wrong, it's coming from Google (as I use gmail) so that was the problem, I have to open the port 25 to any computer not just my hostgator server.. Have a great day. Bye. On Thu, Aug 3, 2017, 16:25 tlhackque via Mailman-users < mailman-users(a)mailman3.org> wrote: > On 03-Aug-17 17:14, Rafael Mora wrote: > > > > > > El jue., 3 ago. 2017 a las 16:07, tlhackque via Mailman-users > > (<mailman-users(a)mailman3.org <mailto:mailman-users@mailman3.org>>) > > escribió: > > > > You've said you're working with labbrands.com <http://labbrands.com > >. > > > > labbrands.com <http://labbrands.com> has address > 192.185.51.89 > > mail.labbrands.com <http://mail.labbrands.com> has address > > 192.185.51.89 > > www.labbrands.com <http://www.labbrands.com> is an alias for > > labbrands.com <http://labbrands.com>. > > > > telnet proves that Exim is running on that IP address. Either you're > > running it, or hostgator is redirecting the SMTP ports. > > > > You added: > > lists.labbrands.com <http://lists.labbrands.com> has address > > 190.145.27.66 > > > > Presumably that's a different machine. > > > > So that now needs an MX record, and a firewall routing. > > > > > > I added the MX record on our hostgator hosting like this: > > image.png > > > > Is it correct??? > > > No. And sending images to the mailing list doesn't get you help. > > You set up lists.labbrands.com as a secondary server, not an independent > mail domain. This will cause you serious grief. > > You need to get some help from a more suitable list. Setting this up is > not mailman-specific, and getting it right is more than a quick note. > > Try the Postfix documentation & mailing lists. > > > > > > > And the SPF > > records ... and spam and virus filters, and all the other stuff > > you need > > to setup an independent, public-facing smtp server. > > > > But at least you won't have to relay. > > > > Good luck. > > > > On 03-Aug-17 16:55, Rafael Mora wrote: > > > El jue., 3 ago. 2017 a las 15:49, tlhackque via Mailman-users (< > > > mailman-users(a)mailman3.org <mailto:mailman-users@mailman3.org>>) > > escribió: > > > > > >> I think you're confused. > > >> > > >> You already have mail.labbrands.com <http://mail.labbrands.com> > > set up as the MX record for > > >> labbrands.com <http://labbrands.com>. And it has an A record > > with the same address as your > > >> webserver. > > >> > > > I'm working with the hostgator mailserver, we are not running a > > local > > > mailserver. > > > > > > As suggested I added an A record like this: > > > [image: image.png] > > > > > > Is it correct? is it redirecting to my Ip so I can redirect it to > my > > > postfix/mm3 server? > > > > > > > > >> So if you're getting e-mail on that domain, there's another e-mail > > >> server running on that IP address. You can't have 2 servers > > on port > > >> 25. In that case, as has been noted before, you'll need to setup > a > > >> relay in that server, not a firewall redirect. Depending on > > your MTA, > > >> you would need to relay to your internal server. And make sure > > your > > >> firewall setup allows your MTA to do this. > > >> > > >> We can see it's EXIM: > > >> > > >> telnet mail.labbrands.com <http://mail.labbrands.com> 25 > > >> Trying 192.185.51.89... > > >> Connected to mail.labbrands.com <http://mail.labbrands.com> > > (192.185.51.89). > > >> Escape character is '^]'. > > >> help > > >> 220-gator4137.hostgator.com > > <http://220-gator4137.hostgator.com> ESMTP Exim 4.87 #1 Thu, 03 > > Aug 2017 15:47:48 > > >> -0500 > > >> 220-We do not authorize the use of this system to transport > > unsolicited, > > >> 220 and/or bulk e-mail. > > >> 214-Commands supported: > > >> 214 AUTH STARTTLS HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP > > >> quit > > >> 221 gator4137.hostgator.com <http://gator4137.hostgator.com> > > closing connection > > >> Connection closed by foreign host. > > >> > > >> Or, consolidate all your e-mail to one server - which is a lot > > easier to > > >> manage unless you have a really big operation. Postfix is > > probably the > > >> right choice, but requires more setup. > > >> > > >> Although Mailman3 configuration is not well documented (as you've > > >> discovered), you may want to get help from someone with more > > general > > >> network and mail experience. You're now into territory that is, > as > > >> Simon indicated, not Mailman-specific. > > >> > > >> On 03-Aug-17 16:28, Rafael Mora wrote: > > >>> El jue., 3 ago. 2017 a las 15:26, Mark Sapiro > > (<mark(a)msapiro.net <mailto:mark@msapiro.net>>) > > >> escribió: > > >>>> On 08/03/2017 01:22 PM, Rafael Mora wrote: > > >>>>> El jue., 3 ago. 2017 a las 15:18, Mark Sapiro > > (<mark(a)msapiro.net <mailto:mark@msapiro.net>>) > > >>>> escribió: > > >>>>>> You need to forward port 25 for SMTP mail delivery and if > > you want the > > >>>>>> web UI (Postorius and HyperKitty) accessible from the > > outside, port 80 > > >>>>>> for http and/or port 443 for https > > >>>>>> < > > >>>>>> > > >> > > > https://www.iana.org/assignments/service-names-port-numbers/service-names-p… > > >>>>>>> . > > >>>>> I mean for incoming mail redirected from my hostgator > > hosting, because > > >>>> when > > >>>>> I suscribe an email address MM3 sends a confirmation email, > > so I have > > >> to > > >>>>> reply to be suscribed to the list. > > >>>> As I said, for mail delivery you need to forward port 25 to > > the Mailman > > >>>> server. > > >>>> > > >>> Ok so I'll redirect in my zentyal firewall the port 25 to my > local > > >> centos7 > > >>> with postfix and MM3 with IP 192.168.1.42. Thanks Mark. > > >>> > > >>> > > >>>> -- > > >>>> Mark Sapiro <mark(a)msapiro.net <mailto:mark@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 <mailto:mailman-users@mailman3.org> > > >>>> > > > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > > >>>> > > >> -- > > >> This communication may not represent my employer's views, > > >> if any, on the matters discussed. > > >> > > >> _______________________________________________ > > >> Mailman-users mailing list > > >> mailman-users(a)mailman3.org <mailto:mailman-users@mailman3.org> > > >> > > > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > > >> > > > > -- > > This communication may not represent my employer's views, > > if any, on the matters discussed. > > > > _______________________________________________ > > Mailman-users mailing list > > mailman-users(a)mailman3.org <mailto:mailman-users@mailman3.org> > > > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > > > > -- > > > > Atentamente / Best Regards > > > > Ing. Rafael Mora > > > > -- > This communication may not represent my employer's views, > if any, on the matters discussed. > > _______________________________________________ > 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

Re: REST API notes

by tlhackque

On 28-Jun-17 23:19, Barry Warsaw wrote: > On Jun 28, 2017, at 01:47 AM, tlhackque--- via Mailman-users wrote: > >> As a beginner with the REST API, I found it necessary to read code and >> experiment to figure out how to get things done. > Thanks for the feedback. Other than the work supporting Postorius and > HyperKitty, I think you've done some of the more extensive exploration of the > REST API, so your comments here (and greatly appreciated bug reports) are > quite valuable, and I think will help us make the REST API both more usable > and more discoverable. I didn't plan to become so involved, but that's what happens when one tries to use something new - perhaps for a slightly unexpected purpose. > It's important to point out some history of the REST API. I understand/expected that there was history; there is still art and evolution in software design. I hope the tone doesn't come across as critical; I only mean to report what I found so you see it from outside the development bubble. > based traversal, I was able to port the extensive existing REST implementation > to the new underlying library fairly easily. > > All this to say that some of the problems you describe are due to historical > accident. And that's served us well(-ish) while we only had to support > mailmanclient and P/HK. But as the REST API is used in more places, those > deficiencies are becoming more glaring. I think if we ever make progress on > Lemme (our authenticating REST proxy), we'll likely encounter the same > problems. But at this point, it's infeasible to completely reimplement the > REST machinery. I don't think it needs to be re-implemented. There are some some fairly simple things that could address the challenges I've found. I'll try to add some notes to/add new bug reports as I have a chance. (But I'm really trying to make progress on my project, of which this is a small part...) > > Much of that is because these are doctests, i.e. testable documentation. It's > a tradeoff between making them useful as docs but also testable without too > much clutter. It's very much oriented toward Python because that makes > testability easier. It would be good to have documentation for pure HTTP/JSON > consumers, but it would be imperative for that also to be testable so we're > sure it remains accurate, aside from any requirements to keep the docs in > sync. Suggestions and contributions would be very much welcome here. If the APIs are supposed to be equivalent, I'd try to define a consistent mapping between the http (S!) API and the internal Python API. Since the implementation is pretty consistent, that shouldn't be too painful. If that can be done, then the same tests can verify the Python API and prove that the HTTP functions are equivalent. The other thing to consider is some tests that are higher level and can become documentation examples. E.g. Starting with an empty installation, create a list with an owner and a subscriber. Which would be in order, every API call necessary to implement this, and then verify (with GETs) that all the objects exist with the right properties. Currently that takes me about 220 lines of source (Perl, includes blank and closing '}' lines, but still...) Not counting loops, I think there are 10 places where I call the API for what is expected to be an 'atomic' create of a list. >> The REST API has a hybrid interface: Requests are made with >> application/x-www-form-urlencoded POST, PUT, PATCH and delete http requests. >> Requests are also accepted as parameter strings. >> >> The responses are JSON. (This is rather surprising - one would expect JSON >> requests - and I hope someday they'll be accepted, as the split complicates >> clients. I suspect this evolved to simplify the initial Web GUI client >> (Postorious), but it precludes using standard JSON-in/JSON-out client >> libraries.) > Absolutely. I want to support JSON-in/JSON-out. Again, the current mismatch > is due to historical implementation decisions, but there's nothing in > principle preventing us from accepting JSON in, afaict. We'd have to continue > to accept both, for backward compatibility reasons. I noted somewhere that this should be easy to implement. I expect that you get an associative array ("dict"?) with the webform parameters. Decoding JSON also ususally provides an associative array. The parameters have the same name. So you should be able to address this at your API entry point, e.g. if the inbound request is Content-Type: application/json, decode as JSON; if x-www-forms-urlencode, decode as today. Then you have the same parameters, and they go downstream for decoding in the array - again as today. I haven't looked at the code (not being a Python person), but I'd be surprised if this was not feasible. >> Error responses are often misidentified as content-type: application/json, >> but actually contain a text/plain error message. This isn't universally >> true; for example the 401 response actually IS JSON. A client has to guess >> and handle decoding exceptions. > That's clearly a bug. The Content-Type should always be accurate. It would > be a new feature to also support JSON error responses. Except that for some responses, you already do... > >> The API presents resources hierarchically, rooted at '/'. The top level >> resources include /users, /lists. /addresses, /domains, /system >> >> The next level is a resource id. > Kind of. It all depends on what the top-level resource is returned. This > makes sense when you think about the object based traversal machinery. > > Each path component points internally to an object, and the subsequent path > component is handled by that object. If that returns another object, then the > next remaining path component is consumed by *that* object. And so on until > we reach the end of the path. Then the object at the leaf responds to the > HTTP command, and each object knows how to represent itself as JSON, and it > knows its canonical location within the resource tree (there can be multiple > paths to any particular object, but there's always one canonical location). That's a better description from inside. I was trying to summarize what it looks like to someone trying to use the API.... > >> There is a an id which is stable for the lifetime of an object, and a current >> name (which can be changed). For example, a list has a name like >> mylist(a)example.com, and a list_id of mylist.example.com. But if you change >> the list name, it becomes mynewname(a)example.net, while the list_id remains >> mylist.example.com. > Lists are weird in that they have two identifiers. One is the posting > address, what we internally (and slightly incorrectly) call the "fully > qualified list name". I don't particularly like that nomenclature anymore, > but we live with it. We all have similar artifacts in any non-trivial code... > A posting address can change, e.g. if you rename or rehome a list. > > The (RFC 2919) List-ID is assigned when the mailing list is created and it's > immutable. Section 4 discourages changing the List-ID and Mailman takes that > as a requirement. Rename a list or rehome it to a different domain on the > same server and the List-ID will never change. Yes. > Again for historical reasons, many APIs both internal and external used the > posting address to identify the list, but this is wrong exactly because that > can change. I've slowly been converting APIs to accept both the posting > address and the List-ID when identifying the mailing list. New APIs generally > accept only the List-ID. Bottom line, it's best to use the List-ID. I noticed that, and indeed go to some pains to fetch the list_id for chained operations. >> Lists are associated with "domains", which are the "domain part" of the >> list's address. That is, the part after the @. This is sometimes referred >> to as the "mail host", but there need not be a real host. > Yep, again historical nomenclature. I understand the history. But I was very, very confused by the overlaid uses. Even in the GUI, I couldn't decide what I should enter. (And I'm fairly familiar with e-mail RFCs and history...perhaps that's my problem.) Documentation needs improvement. Feel free to use (or improve) my words. > >> A domain has to be created before you can create a list with an address in >> that domain. > Some APIs (e.g. `mailman create` CLI) will create the domain automatically if > it doesn't already exist, and unless you disable that explicitly. I was writing exclusively about the REST API. I couldn't create a list without the domain, so I create the domain unconditionally (and ignore the 'it exists' error); that's cheaper than query+create. "Create if not exists" would be a useful API extension, since clients would see a success code either way. (200 OK for exists, 201 Created for new). > >> Resources are created with a POST to their top-level resource. To create a >> domain, post to /domains with mail_host => the domain, and (optionally) >> description => a description for the GUI. The response isn't JSON as one >> would expect. In fact, it's an empty application/json response with a 201 >> status. >> >> To create a list, one POSTs to /lists. This post takes a restricted set of >> parameters; in the case of a list, just its fqdn_listname, (and an optional >> style - which isn't well defined). The response isn't JSON as one would >> expect. The Location header of the response contains a URL of the new list. > What else would you expect? From my reading of books like RESTful Web > Services (admittedly a long while ago), that's exactly the proper response to > an appending POST. Return a 201 with a Location header to the new resource > and empty content. I didn't read the book - but I have talked to a number of services that claim to provide a RESTful API. Of course, REST is a style, not a specification, so mileage varies... I would expect the new resource address to be in the JSON body of the response. I don't mind the Location header (if you imagine the response to be a 301, it kind of makes sense). But a client (well, at least mine) wants a consistent place to look for the result of an operation. That would be the HTTP Status + JSON reply. This is inconsistent - and with JSON REST client libraries, it turns out to be more difficult to get at the headers. (I patched the one that I use...) My 3 cents: if an interface is JSON, it should be usable entirely as JSON. JSON in, all JSON out.... This simplifies life for a client: Get a response, decode the JSON - and everything is in the decoded JSON (usually an array or associative array in whatever language). Not some in the JSON, some in the Response headers (and some in the HTTP status - which usually is replicated in the response JSON), and some plaintext in the response body. > >> To configure the list, you have to follow up with a PUT or PATCH to that URL >> + /config This is where you can set the description, posting policy, etc. >> It's unrealistic to do a PUT; even if you're cloning another list, there's no >> programatic way to determine which attributes are writable. PATCH what you >> know... > Mailing list resources are somewhat unique in that they probably have the most > properties of any resource/object in the system. That's not surprising if you > think about it, but it does make PUTing to a mailing list more or less > impractical. That's certainly not true of other, smaller resources though, > and of course, you still want symmetry there (plus, implementation-wise, it's > almost a no brainer to support both PUT and PATCH). The problem is that from a client, there is no way to know which attributes are writable, and which are immutable. So get (template), modify, put (new) doesn't work. There should be a way to find out what attributes are writable. Or the API could ignore writes to immutable attributes, and return "success" (or in a JSON reply, "partial succes") to the client.... >> Members are associated with e-mail addresses - which belong to Users. > Users can have multiple addresses, addresses can be linked to only one user, > but may be unlinked, and members associate "subscribers" to mailing lists, > where a subscriber is either a user-with-preferred-address, or an address. I saw that. I didn't look into the unlinking part, as (oddly enough) I'm only trying to do a restricted subset of the possible operations. All I need to do is create & configure a list (with a couple of members) on-the fly. (Oh, and post an announcement of the fact on a related list.) The tricky part is that it's all done without human intervention. >> You create a user by posting to /users with email => the email address, and >> optionally display_name => the name string. (A user can also be implicitly >> created by subscribing an e-mail address, but that gets confusing.) The >> e-mail address is the primary email address for the user. More later. >> Again, you get a Location header in the response, which you can use to PATCH >> /preferences to set delivery_status, etc. .These preferences are part of a >> hierarchy - many have a system default, a list default, the user default, and >> a subscription to that list value. You can find the User associated with a >> list by a GET of /addresses/address(a)example.net. > Technically, the returned user isn't necessarily associated with a list. It > *may* be subscribed to the list, but that relationship is represented by a > member. I understood that. > >> This GET returns two URLs: user => the user owning this address, and >> self_link => the address object. > *All* resources in the REST API have a self_link, and while that may seem > redundant, it's not. As mentioned above, you can take various paths through > the resource tree to get to a particular resource, but regardless of that, > every resource has exactly one canonical location. That location is > represented by the self_link. Yes. >> Note also that there are both an email and original_email attribute. The >> latter preserves case. The former is used internally by Mailman as a >> resource key, etc. (Though exactly what happens if John(a)example.net and >> john(a)example.net both subscribe is unclear.) > They can't. Mailman is case-preserving case-insensitive for email addresses. > Technically speaking, john(a)example.com and JOHN(a)example.com can be different > mailboxes, but that never happens in practice anymore, and Mailman has always > explicitly treated them as the same address. This goes back to the earliest > days of Mailman. I still run into systems that demand exact case for delivery. I agree that two different humans assigned to such a mailbox would go (or already are) crazy. But I have seen John using john and JOHN as two different identities. I havesuggested using '+' subaddressing instead. Then again, 70% of of the e-mail address validators that people come up with reject clark+kent(a)example.net because of the '+'... I am curious as to whether anything breaks if I subscribe to a mailman list with a plus address, but it's low on my list... >> Once a list is configured, you can add members. This requires the list_id - >> which you don't (officially) have. So you do a GET on the list resource, to >> get the list_id. Then you can subscribe a member with list_id => (the list >> id), subscriber => email address. Optionally you can >> pre_verify/confirm/approve the member and/or add a display_name.. POST to >> /members. Again, you get a Location header back. You can't specify >> everything you might like. as a creation attribute. So you may have to PATCH >> the member to, for example, set the moderation_status. > This is true, but it also kind of makes sense if you grok the way preferences > work, i.e. hierarchically as you describe above. TBH, I don't particularly > like the way preferences are modeled either internally or through the REST > API, but I haven't been able to come up with anything better. > >> You may also need to PATCH the member /preferences if you want to set >> list-level delivery status, etc. > All true. In each of those cases, you may be talking to a different > preference resource. > >> Consider adding at least an owner when creating a list. > I think that would be a useful addition to the REST API for list creation. > >> One challenge is that almost everything requires multiple REST operations to >> set up. But REST (by definition) is stateless. So the best you can do is >> order operations & hope. > I don't understand this. REST is stateless, but not all HTTP operations are > idempotent. POST certainly isn't, by definition, so if you use it to create a > new resource under a collection, you clearly cannot modify that resource > through PUT or PATCH until the resource is created, which only happens when > POST succeeds. I've written up an issue on this with some more detail/thoughts and will post (er, no pun intended) it shortly. The short form is that (as noted below), I want a list to atomically create a list - either it exists (configured the way I need it to be), or it doesn't exist. That's not possible. So I create a domain, create a user, configure the user, create a list, configure the list, add the user - but at any point in the middle, a message could arrive for the non-quite-configured list. This isn't good... > >> The mailman client examples refer to transactions (e.g in users.rst, there is >> 'transaction.commit(); - but REST can't hold state. It does appear that the >> server uses DB transactions to ensure that any given REST operation is ACID, >> but the composite operations (e.g. create a list and set it's config) can not >> be Atomic. This is an architectural flaw in the API. > I think what you're getting at is that some POSTs to create new resources do > not accept the same parameters as the subsequent PUT or PATCH on the newly > created resource. I think that may be true, but it's not universally so. > E.g. POST on /domain creates a new domain, returning the location of the new > resource. You can provide both a description and an owner, and you can also > provide a mail_host. But mail_host is immutable, and PATCH or PUT support > changing all mutable attributes on the domain. > > That should be the general rule; if an attribute on a resource is mutable, you > should be able to PATCH and PUT it, *and* you should be able to specify all > mutable attributes, plus some immutable ones on the POST that creates the > resource. Yes. I can't specify everything about an object on many posts - list creation the the most glaring example. Also, things linked to the object - e.g. if I create a member, I have to: POST (create the member); PATCH (set moderation_action; PATCH(preferences) to set (delivery_status,hid_address,receive_list_copy,receive_own_postings). That's three REST calls for what should be one - ATOMIC transaction. Plus, this is separate from the list creation, so there's a window between creating the list (even if it were atomic - which it isn't) and the time its required members are subscribed. > GET should return all attributes, mutable or immutable. This rule > may not be strictly adhered to for all resources and collections, but I would > consider that a bug, not an architectural flaw. > > AFAIK, this is all working as any well-defined web service should work. >> Symbolic names (which are required) for attributes are in the >> src/mailman/interfaces/(class).py. > Please note that the interfaces under this package are for the *internal* API, > which often, but not always, is exposed in the REST API. These two APIs serve > different purposes so they cannot be a one-to-one mapping, and there are many > resources in the REST API that don't correspond directly to internal objects, > and there are many internal objects that are not exposed to the REST API. There was no other place I could find that defined attribute values for enumerated items. E.g. delivery_status => 'by_user' - interfaces is where I found how to spell 'by_user'. Maybe I missed something more obvious. >> What you can get/set comes from src/mailman/rest/(class).py. > Yes, so clients of the REST API are served by objects in this package. > Plugins and other internal operations are served by the objects that implement > interfaces in the src/mailman/interfaces package. This is a strict separation > of concerns, and it mirrors other 'external facing' interfaces, of which the > command line is another example. I keep struggling with wanting to understand the external model of the API without having to understand the internal implementation. When the API is formally documented, I encourage you to de-emphasize the internal model and concentrate on the external interfaces in client terms... > Hope that helps. Yes, thanks. > -Barry >

8 years, 1 month

Re: New messages not being archived

by Philip Colmer

I'm having exactly the same problem as Sarah. I've built the server using the virtualenv instructions (https://docs.mailman3.org/en/latest/install/virtualenv.html) but archiving of messages is not working. /opt/mailman/mm/var/archives/hyperkitty/spool contains a number of "pck" files. /opt/mailman/mm/var/logs/mailman.log contains entries like this: Sep 03 09:38:17 2021 (3011) Exception in "hyperkitty" archiver Traceback (most recent call last): File "/opt/mailman/venv/lib/python3.8/site-packages/urllib3/connectionpool.py", line 699, in urlopen httplib_response = self._make_request( File "/opt/mailman/venv/lib/python3.8/site-packages/urllib3/connectionpool.py", line 445, in _make_request six.raise_from(e, None) File "<string>", line 3, in raise_from File "/opt/mailman/venv/lib/python3.8/site-packages/urllib3/connectionpool.py", line 440, in _make_request httplib_response = conn.getresponse() File "/usr/lib/python3.8/http/client.py", line 1344, in getresponse response.begin() File "/usr/lib/python3.8/http/client.py", line 307, in begin version, status, reason = self._read_status() File "/usr/lib/python3.8/http/client.py", line 276, in _read_status raise RemoteDisconnected("Remote end closed connection without" http.client.RemoteDisconnected: Remote end closed connection without response curl http://127.0.0.1:8000/archives/ reports: curl: (52) Empty reply from server https://example.com/archives/api/mailman/urls reports: Access is forbidden Please check the IP addresses assigned to MAILMAN_ARCHIVER_FROM in the settings file. /opt/mailman/mm/urls.py doesn't exist on my machine. I've found the following files called urls.py beneath /opt/mailman: 790264 4 -rw-rw-r-- 1 mailman mailman 138 Aug 16 09:23 ./venv/lib/python3.8/site-packages/falcon/bench/dj/dj/urls.py 538719 4 -rw-rw-r-- 1 mailman mailman 615 Aug 16 09:52 ./venv/lib/python3.8/site-packages/rest_framework/urls.py 539156 4 -rw-rw-r-- 1 mailman mailman 1052 Aug 16 09:52 ./venv/lib/python3.8/site-packages/rest_framework/utils/urls.py 1050019 8 -rw-rw-r-- 1 mailman mailman 7222 Aug 16 09:52 ./venv/lib/python3.8/site-packages/postorius/urls.py 797890 8 -rw-rw-r-- 1 mailman mailman 7783 Aug 16 09:52 ./venv/lib/python3.8/site-packages/hyperkitty/urls.py 1298485 4 -rw-rw-r-- 1 mailman mailman 3246 Aug 16 09:52 ./venv/lib/python3.8/site-packages/django/core/checks/urls.py 1051696 4 -rw-rw-r-- 1 mailman mailman 1310 Aug 16 09:52 ./venv/lib/python3.8/site-packages/django/contrib/admindocs/urls.py 1052065 4 -rw-rw-r-- 1 mailman mailman 498 Aug 16 09:52 ./venv/lib/python3.8/site-packages/django/contrib/staticfiles/urls.py 1052096 4 -rw-rw-r-- 1 mailman mailman 179 Aug 16 09:52 ./venv/lib/python3.8/site-packages/django/contrib/flatpages/urls.py 1052339 4 -rw-rw-r-- 1 mailman mailman 1054 Aug 16 09:52 ./venv/lib/python3.8/site-packages/django/contrib/auth/urls.py 785525 4 -rw-rw-r-- 1 mailman mailman 1481 Aug 16 09:23 ./venv/lib/python3.8/site-packages/pip/_internal/utils/urls.py 1050826 4 -rw-rw-r-- 1 mailman mailman 1289 Aug 16 09:52 ./venv/lib/python3.8/site-packages/mailman_web/urls.py 539863 4 -rw-rw-r-- 1 mailman mailman 752 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/urls.py 539871 4 -rw-rw-r-- 1 mailman mailman 1404 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/account/urls.py 539927 4 -rw-rw-r-- 1 mailman mailman 414 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/urls.py 539944 4 -rw-rw-r-- 1 mailman mailman 162 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/zoom/urls.py 539956 4 -rw-rw-r-- 1 mailman mailman 172 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/nextcloud/urls.py 539968 4 -rw-rw-r-- 1 mailman mailman 174 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/dataporten/urls.py 539982 4 -rw-rw-r-- 1 mailman mailman 134 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/persona/urls.py 539999 4 -rw-rw-r-- 1 mailman mailman 174 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/salesforce/urls.py 540011 4 -rw-rw-r-- 1 mailman mailman 170 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/basecamp/urls.py 540023 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/feedly/urls.py 540035 4 -rw-rw-r-- 1 mailman mailman 164 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/baidu/urls.py 540047 4 -rw-rw-r-- 1 mailman mailman 164 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/naver/urls.py 540061 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/stripe/urls.py 540073 4 -rw-rw-r-- 1 mailman mailman 209 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/vimeo_oauth2/urls.py 540087 4 -rw-rw-r-- 1 mailman mailman 164 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/figma/urls.py 540099 4 -rw-rw-r-- 1 mailman mailman 233 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/keycloak/urls.py 540111 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/yandex/urls.py 540123 4 -rw-rw-r-- 1 mailman mailman 162 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/ynab/urls.py 540135 4 -rw-rw-r-- 1 mailman mailman 164 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/asana/urls.py 540149 4 -rw-rw-r-- 1 mailman mailman 164 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/azure/urls.py 540163 4 -rw-rw-r-- 1 mailman mailman 169 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/linkedin/urls.py 540175 4 -rw-rw-r-- 1 mailman mailman 209 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/draugiem/urls.py 540187 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/dwolla/urls.py 540201 4 -rw-rw-r-- 1 mailman mailman 527 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/oauth/urls.py 540213 4 -rw-rw-r-- 1 mailman mailman 224 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/auth0/urls.py 540225 4 -rw-rw-r-- 1 mailman mailman 165 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/flickr/urls.py 540237 4 -rw-rw-r-- 1 mailman mailman 206 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/discord/urls.py 540249 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/amazon/urls.py 540261 4 -rw-rw-r-- 1 mailman mailman 224 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/jupyterhub/urls.py 540273 4 -rw-rw-r-- 1 mailman mailman 174 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/stocktwits/urls.py 540285 4 -rw-rw-r-- 1 mailman mailman 201 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/openid/urls.py 540311 4 -rw-rw-r-- 1 mailman mailman 172 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/angellist/urls.py 540323 4 -rw-rw-r-- 1 mailman mailman 172 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/pinterest/urls.py 540335 4 -rw-rw-r-- 1 mailman mailman 398 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/apple/urls.py 540351 4 -rw-rw-r-- 1 mailman mailman 164 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/yahoo/urls.py 540365 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/twitch/urls.py 540377 4 -rw-rw-r-- 1 mailman mailman 200 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/agave/urls.py 540389 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/strava/urls.py 540401 4 -rw-rw-r-- 1 mailman mailman 163 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/vimeo/urls.py 540413 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/douban/urls.py 540425 4 -rw-rw-r-- 1 mailman mailman 164 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/weibo/urls.py 540437 4 -rw-rw-r-- 1 mailman mailman 529 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/oauth2/urls.py 540449 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/disqus/urls.py 540461 4 -rw-rw-r-- 1 mailman mailman 162 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/daum/urls.py 540475 4 -rw-rw-r-- 1 mailman mailman 203 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/globus/urls.py 540487 4 -rw-rw-r-- 1 mailman mailman 171 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/box/urls.py 540499 4 -rw-rw-r-- 1 mailman mailman 180 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/odnoklassniki/urls.py 540511 4 -rw-rw-r-- 1 mailman mailman 168 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/shopify/urls.py 540523 4 -rw-rw-r-- 1 mailman mailman 209 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/steam/urls.py 540535 4 -rw-rw-r-- 1 mailman mailman 201 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/patreon/urls.py 540549 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/mailru/urls.py 540561 4 -rw-rw-r-- 1 mailman mailman 137 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/telegram/urls.py 540571 4 -rw-rw-r-- 1 mailman mailman 179 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/fivehundredpx/urls.py 540585 4 -rw-rw-r-- 1 mailman mailman 169 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/evernote/urls.py 540597 4 -rw-rw-r-- 1 mailman mailman 164 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/kakao/urls.py 540611 4 -rw-rw-r-- 1 mailman mailman 162 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/cern/urls.py 540623 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/reddit/urls.py 540635 4 -rw-rw-r-- 1 mailman mailman 164 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/orcid/urls.py 540647 4 -rw-rw-r-- 1 mailman mailman 160 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/edx/urls.py 540659 4 -rw-rw-r-- 1 mailman mailman 165 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/tumblr/urls.py 540671 4 -rw-rw-r-- 1 mailman mailman 170 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/doximity/urls.py 540683 4 -rw-rw-r-- 1 mailman mailman 170 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/frontier/urls.py 540695 4 -rw-rw-r-- 1 mailman mailman 172 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/instagram/urls.py 540707 4 -rw-rw-r-- 1 mailman mailman 164 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/hubic/urls.py 540719 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/weixin/urls.py 540733 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/google/urls.py 540745 4 -rw-rw-r-- 1 mailman mailman 168 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/untappd/urls.py 540759 4 -rw-rw-r-- 1 mailman mailman 217 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/eventbrite/urls.py 540771 4 -rw-rw-r-- 1 mailman mailman 174 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/foursquare/urls.py 540786 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/meetup/urls.py 540800 4 -rw-rw-r-- 1 mailman mailman 172 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/authentiq/urls.py 540812 4 -rw-rw-r-- 1 mailman mailman 172 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/battlenet/urls.py 540828 4 -rw-rw-r-- 1 mailman mailman 227 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/gitlab/urls.py 540840 4 -rw-rw-r-- 1 mailman mailman 224 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/netiq/urls.py 540852 4 -rw-rw-r-- 1 mailman mailman 168 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/cilogon/urls.py 540864 4 -rw-rw-r-- 1 mailman mailman 172 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/robinhood/urls.py 540876 4 -rw-rw-r-- 1 mailman mailman 170 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/coinbase/urls.py 540888 4 -rw-rw-r-- 1 mailman mailman 171 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/bitbucket/urls.py 540900 4 -rw-rw-r-- 1 mailman mailman 360 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/facebook/urls.py 540925 4 -rw-rw-r-- 1 mailman mailman 174 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/soundcloud/urls.py 540937 4 -rw-rw-r-- 1 mailman mailman 172 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/eveonline/urls.py 540949 4 -rw-rw-r-- 1 mailman mailman 234 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/amazon_cognito/urls.py 540963 4 -rw-rw-r-- 1 mailman mailman 162 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/line/urls.py 540977 4 -rw-rw-r-- 1 mailman mailman 184 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/fxa/urls.py 540991 4 -rw-rw-r-- 1 mailman mailman 182 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/linkedin_oauth2/urls.py 541003 4 -rw-rw-r-- 1 mailman mailman 180 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/trainingpeaks/urls.py 541015 4 -rw-rw-r-- 1 mailman mailman 176 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/windowslive/urls.py 541027 4 -rw-rw-r-- 1 mailman mailman 180 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/stackexchange/urls.py 541039 4 -rw-rw-r-- 1 mailman mailman 182 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/microsoft/urls.py 541053 4 -rw-rw-r-- 1 mailman mailman 186 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/quickbooks/urls.py 541067 4 -rw-rw-r-- 1 mailman mailman 179 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/openstreetmap/urls.py 541079 4 -rw-rw-r-- 1 mailman mailman 214 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/mailchimp/urls.py 541091 4 -rw-rw-r-- 1 mailman mailman 164 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/bitly/urls.py 541103 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/paypal/urls.py 541115 4 -rw-rw-r-- 1 mailman mailman 167 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/twitter/urls.py 541127 4 -rw-rw-r-- 1 mailman mailman 183 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/bitbucket_oauth2/urls.py 541139 4 -rw-rw-r-- 1 mailman mailman 179 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/spotify/urls.py 541151 4 -rw-rw-r-- 1 mailman mailman 164 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/exist/urls.py 541163 4 -rw-rw-r-- 1 mailman mailman 178 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/digitalocean/urls.py 541175 4 -rw-rw-r-- 1 mailman mailman 186 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/twentythreeandme/urls.py 541187 4 -rw-rw-r-- 1 mailman mailman 179 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/dropbox/urls.py 541199 4 -rw-rw-r-- 1 mailman mailman 162 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/okta/urls.py 541211 4 -rw-rw-r-- 1 mailman mailman 172 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/sharefile/urls.py 541223 4 -rw-rw-r-- 1 mailman mailman 164 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/slack/urls.py 541237 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/edmodo/urls.py 541249 4 -rw-rw-r-- 1 mailman mailman 191 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/feishu/urls.py 541263 4 -rw-rw-r-- 1 mailman mailman 166 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/github/urls.py 541275 4 -rw-rw-r-- 1 mailman mailman 161 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/xing/urls.py 541287 4 -rw-rw-r-- 1 mailman mailman 165 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/trello/urls.py 541299 4 -rw-rw-r-- 1 mailman mailman 158 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/vk/urls.py 541311 4 -rw-rw-r-- 1 mailman mailman 162 Aug 16 09:52 ./venv/lib/python3.8/site-packages/allauth/socialaccount/providers/zoho/urls.py 538780 4 -rw-rw-r-- 1 mailman mailman 1121 Aug 16 09:52 ./venv/lib/python3.8/site-packages/django_mailman3/urls.py 539115 4 -rw-rw-r-- 1 mailman mailman 1076 Aug 16 09:52 ./venv/lib/python3.8/site-packages/django_mailman3/lib/auth/fedora/urls.py 536453 4 -rw-rw-r-- 1 mailman mailman 156 Aug 16 09:52 ./venv/lib/python3.8/site-packages/haystack/urls.py 537504 4 -rwxrwxr-x 1 mailman mailman 132 Aug 16 09:52 ./venv/lib/python3.8/site-packages/django_q/tests/urls.py

3 years, 11 months

Mailman-users search results for query "Postorius"