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

[MM3-users] Re: External MTA incoming mail: configuration

by Odhiambo Washington

On Wed, Jul 31, 2024 at 2:35 PM Roland Giesler via Mailman-users < mailman-users(a)mailman3.org> wrote: > On 2024/07/30 22:39, Mark Sapiro wrote: > > It appears you have a situation where the MX for the Mailman domains > > is not the Mailman server. You need to configure the MTA on > > box2.gtahardware.co.za to relay Mailman's mail to the mailman server. > > You can to this by configuring that MTA to use transport_maps, etc as > > if it were the Mailman server. In order to get Mailman's generated > > files on the other server, you need to create a process to do that. > > When Mailman makes changes by adding or deleting lists or when it is > > started, it updates the postfix_lmtp and postfix_domains files and > > calls a command (normally postmap) to update the corresponding .db > > files. The command can be set by setting `postmap_command` in the > > `[postfix]` section in mailman.cfg. > > > I'm not able to find any documentation about `postmap_command`, not even > in the schema.cfg. If I have to provide method to update the > postfix_lmtp and postfix_domains on another server, then it would have > to something like sftp? mailman changes the files on the mailman server > (in a location I set) and then postmap_command copies those files to the > destination on the MTA server. Is that in principle what needs to be done? > > thanks again! > Read this thread and take a keen look at the solution provided by @Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> : https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… -- 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]

11 months

[MM3-users] Re: exim4 + mailman3 lmtp failure

by Thomas Drillich

Hello Mark, thank you four your fast response, yes I use the default port 8024 netstat -atp: tcp 0 0 localhost:8024 0.0.0.0:* LISTEN 26555/python >grep MM3_LMTP_PORT /var/lib/exim4/config.autogenerated MM3_LMTP_PORT=8024 lines from exim4/mainlog 2020-05-06 21:48:08.506 [5776] 1jWQ1Y-0001VA-2A <= th(a)drillich.com H=mo4-p00-ob.smtp.rzone.de [85.215.255.20]:20961 I=[85.25.8.21]:25 P=esmtps L- X=TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=no S=7313 M8S=0 DKIM=drillich.com RT=0.146s id=bb5a020a-bcc3-81a2-b5ab-6d89eaf5b28d(a)drillich.com from <th(a)drillich.com> for seebruecke(a)listen.td3.eu 2020-05-06 21:48:08.517 [5776] SMTP connection from mo4-p00-ob.smtp.rzone.de [85.215.255.20]:20961 I=[85.25.8.21]:25 closed by QUIT 2020-05-06 21:48:08.787 [5777] 1jWQ1Y-0001VA-2A ** seebruecke(a)listen.td3.eu F=<th(a)drillich.com> P=<th(a)drillich.com> R=mailman3_router T=mailman3_transport: all hosts for 'listen.td3.eu' have been failing for a long time (and retry time not reached) Am 06.05.20 um 20:55 schrieb Mark Sapiro: > On 5/6/20 10:54 AM, Thomas Drillich wrote: >> Hello, >> >> I tried to setup exim4 + mailman3 but it seems to stuck at lmtp delivery of mailman3. >> Could you give me a hint, to detect the reason of failure ? > ... >> # /etc/exim4/conf.d/transport/55_mm3_transport >> mailman3_transport: >> driver = smtp >> protocol = lmtp >> allow_localhost >> hosts = localhost >> port = MM3_LMTP_PORT >> rcpt_include_affixes = true > Have you defined MM3_LMTP_PORT and is it the same value as the > lmtp_port: setting in the [mta] section of mailman.cfg - default 8024? > > And is Mailman core and particularly its lmtp runner running and is it > listening on the relevant port? > > Is there more information about "all hosts for 'listen.td3.eu' have been > failing for a long time" in exim's logs? > > > _______________________________________________ > 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/ -- mit freundlichem Gruss -- regards Thomas Drillich Heugasse 4 / D-55116 Mainz / Germany fon +49-6131-570-2621 mobil +49-162-469-5875

5 years, 1 month

[MM3-users] Re: Postorius confirmation mails shown in uwsgi-error.log but not sent

by Abhilash Raj

On Mon, Mar 30, 2020, at 5:33 AM, Ralph Seichter wrote: > * Mark Sapiro: > > >> $ grep ^EMAIL settings.py > >> EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend' > >> EMAIL_HOST = 'localhost' > >> EMAIL_PORT = 25 > > > > but is this perhaps overridden in a settings_local.py file? > > I don't have a local settings file. I cloned the suite from GitLab[1] > master branch and modified the existing settings.py, based on Mailman's > documentation. > > [1] https://gitlab.com/mailman/mailman-suite.git > > I just verified that EMAIL_BACKEND is not redefined anywhere: > > $ grep -r 'mail\.backends' . > Binary file ./__pycache__/settings.cpython-38.pyc matches > ./settings.py:EMAIL_BACKEND = > 'django.core.mail.backends.smtp.EmailBackend' > ./settings.py:# EMAIL_BACKEND = > 'django.core.mail.backends.filebased.EmailBackend' > > I commented out the "if DEBUG == True" lines, which explains match > number three. As far as I can see, the mail backed definition for Django > is as it should be. > > I could provide the differences between my settings.py and the Git HEAD > version if you think that might help. It definitely would help if you paste the diff of the settings required. Also, can you jump into a django shell and see if you can get any exceptions trying to send emails: $ python manage.py shell >>> from django.core.mail import send_mail >>> send_mail( 'Subject here', 'Here is the message.', 'from(a)example.com', ['to(a)example.com'], fail_silently=False, ) I picked it up from the Django's docs and perhaps fail_silently=False would give some exceptions. Please make sure you tail the logs for any connections. Abhilash > > -Ralph > _______________________________________________ > 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/ > -- thanks, Abhilash Raj (maxking)

5 years, 3 months

[MM3-users] Re: External MTA incoming mail: configuration

by Roland Giesler

On 2024/07/31 13:47, Odhiambo Washington via Mailman-users wrote: > On Wed, Jul 31, 2024 at 2:35 PM Roland Giesler via Mailman-users < > mailman-users(a)mailman3.org> wrote: > >> On 2024/07/30 22:39, Mark Sapiro wrote: >>> It appears you have a situation where the MX for the Mailman domains >>> is not the Mailman server. You need to configure the MTA on >>> box2.gtahardware.co.za to relay Mailman's mail to the mailman server. >>> You can to this by configuring that MTA to use transport_maps, etc as >>> if it were the Mailman server. In order to get Mailman's generated >>> files on the other server, you need to create a process to do that. >>> When Mailman makes changes by adding or deleting lists or when it is >>> started, it updates the postfix_lmtp and postfix_domains files and >>> calls a command (normally postmap) to update the corresponding .db >>> files. The command can be set by setting `postmap_command` in the >>> `[postfix]` section in mailman.cfg. >> >> I'm not able to find any documentation about `postmap_command`, not even >> in the schema.cfg. If I have to provide method to update the >> postfix_lmtp and postfix_domains on another server, then it would have >> to something like sftp? mailman changes the files on the mailman server >> (in a location I set) and then postmap_command copies those files to the >> destination on the MTA server. Is that in principle what needs to be done? >> > Read this thread and take a keen look at the solution provided by @Stephen > J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> : > > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… Excellent! I think I can get the sshfs route working, but the pending database solution is elegant! I love it! Thanks for the pointer.

11 months

[MM3-users] Re: SPF check fails for lists subdomain

by Jan Eden

On 2023-01-05 08:55, Jan Eden via Mailman-users wrote: > On 2023-01-04 15:07, Mark Sapiro wrote: > > On 1/4/23 14:02, Jan Eden via Mailman-users wrote: > > > Although I could specify the IP address in my SPF records directly (as > > > you suggested), I do hope that my understanding of DNS records laid out > > > above is not entirely misguided. My current setup does work as expected > > > for eden.one, after all. > > > > As I said at <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…> > > I was misreading your DNS and now I am as puzzled as you about the failure. > > It gets even more mysterious. I tried sending messages from both > lists.eden.one and janeden.net (my other domain) to a gmail account and > to another mail provider. Both messages passed the SPF checks on both > services (s. the relevant headers quoted below). Now because I send > those messages via my SMTP user (smtpuser(a)eden.one) and use SRS, the SPF > check operates (and succeeds) on e.g. > srs0=jdm+=5c=lists.eden.one=testlist-bounces+gmailuser=googlemail.com(a)eden.one > (and not on somethingsomething(a)lists.eden.one or > somethingsomething(a)janeden.net) Could this be the reason for the failed > SPF checks in Yahoo's and Google's DMARC reports? There was never a mystery, just my complete ignorance wrt DMARC and alignment[1]. Changing the DMARC DNS entry for lists.eden.one (more specifically, the aspf tag) solved the issue: <policy_published> <domain>lists.eden.one</domain> <adkim>s</adkim> <aspf>r</aspf> <p>quarantine</p> <sp>quarantine</sp> <pct>75</pct> </policy_published> <record> <row> <source_ip>123.123.123.123</source_ip> <count>1</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>pass</spf> </policy_evaluated> </row> For other domains, I would need to turn off SRS, which is not possible for independent reasons. - Jan [1] https://en.wikipedia.org/wiki/DMARC#Alignment

2 years, 5 months

[Test] Re: What now -reply from web

by Simon Hanna

On 03/21/2016 03:36 AM, Mark Sapiro wrote: > On 03/20/2016 07:22 PM, mailman(a)mailman3.org wrote: >> The last post with SSL = True and latest core still hits the same >> underlying exception both in trying to get the archive URL and in >> trying to archive the message. The core now handles these exceptions >> and continues so the message goes to the list, but isn't archived and >> has no archive headers. >> >> This is a post from hyperkitty which will probably be handled the >> same, so we have to go back to SSL = False until we can fix the >> certificate issue. > > > Yes. > > Bottom line. With USE_SSL = True, core connects to hyperkitty via SSL to > 127.0.0.1 and the certificates I installed don't include 127.0.0.1 in > their domains, so urllib3 or requests (depending on where we're coming > from) throws SSLError: hostname '127.0.0.1' doesn't match either of > 'lists.mailman3.org', 'mirror.list.org', 'mirror.mailman3.org'. > > The core now handles the exceptions and the message is ultimately > delivered but not archived. regardless of where it originated. > > We're back to USE_SSL = False now so this post should be archived, > albeit the archive URLs will have 127.0.0.1 ast the host and not > lists.mailman3.org. IMHO you shouldn't use USE_SSL at all. It just redirects to ssl pages on certain urls in hyperkitty. What you should be doing is having your webserver (nginx, apache, ...) redirect all trafic from http to https. I'm doing this and have the following settings: # django settings USE_SSL = False # Put external IP in this tuple MAILMAN_ARCHIVER_FROM = ('x.x.x.x', '127.0.0.1', '::1') # hyperkitty archiver plugin # this is the url to the base page of hyperkitty # in your case this would be # base_url: https://lists.mailman3.org/archives/ base_url: https://example.com/hyperkitty/ It's working like a charm with no errors at all

9 years, 3 months

[MM3-users] Re: Help request, almost got it going, but ....

by Claus-Justus Heine

I have fixed the bug on forks of mailman-core, postorius and mailman-client. C Am 02.09.2017 um 14:36 schrieb Claus-Justus Heine via Mailman-users: > I think I found the bug; I have posted a comment to the issue mentioned > by Mark > > https://gitlab.com/mailman/postorius/issues/58 > > Regards > > Claus > > Am 02.09.2017 um 01:20 schrieb Claus-Justus Heine via Mailman-users: >> Oh well. >> >> Am 01.09.2017 um 23:44 schrieb Mark Sapiro: >>> On 09/01/2017 02:33 PM, Claus-Justus Heine via Mailman-users wrote: >>>> >>>> Seemingly, at some point in the deep dungeons of the source code the >>>> "Acceptable aliases" Text-Box is not interpreted correctly. >>>> >>>> Specifically, at the start it contains the string >>>> >>>> [] >>> >>> >>> See <https://gitlab.com/mailman/postorius/issues/58>. >> >> there they talk about fancy "uni-code thinks" (email addresses?) where >> the task is to convert a new-line separated text-field into an array. Oops. >> >> Kind thanks anyway. >> >>> >>> In order to set things on this page, you need to clear the Acceptable >>> aliases box before submitting changes. You can't actually set Acceptable >>> aliases via Postorius until this is fixed. >> >> The issue seems not to be overly active. I thought -- coming from >> Mailman v2 -- that the configuration of acceptable submitters to an >> email list (e.g. keep everyone moderated?) would be a central and >> prominent and important configuration issue. Seems not to be a central >> point. Mmmh. >> >> Thanks >> >> Claus >> >> > -- Claus-Justus Heine himself(a)claus-justus-heine.de http://www.claus-justus-heine.de/ Schatzmeister der Camerata Academica Freiburg e.V. --- www.cafev.de

7 years, 10 months

[MM3-users] Re: re-sending confirmation mails (was Re: Re: pending subscriptions lost?)

by IEM Network Operation Center (IOhannes m zmölnig)

thanks again, Mark, for your detailed answer. On 3/15/22 17:21, Mark Sapiro wrote: > See https://gitlab.com/mailman/mailman/-/issues/901 > > You can add something like > ``` > Alternatively, you can confirm by going to the URL > > https://$domain/mailman3/lists/$list_id/confirm/?token=$token > ``` hmm. the list-url (e.g. where you can subscribe to the list) for my instance looks like https://$domain/postorius/lists/$list_id/ (that is: it spells "postorius" rather than "mailman3"). so i guess the URL should be https://$domain/postorius/lists/$list_id/confirm/?token=$token, which unfortunately returns 404. also, my postorius/urls.py does not contain an url-pattern for "confirm", unlike the current one as found on <https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/urls.py#L83> so i guess this was not possible yet with postorius 1.2.4 > to the list:user:action:subscribe template. Note that `$domain` may not > be appropriate here because it is the email domain which may not be the > web domain. > >> also: the confirmation mail says that the subject must be kept intact. >> however, i noticed that the actual "From" address of the confirmation >> mail already contains the token. > > The current template > https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/templates/en/l… > doesn't say that. yes. the *current* template. but not the template that came with mailman3 3.2.1 > >> finally: what else is required to approve the confirmation? will the >> sender's email-address be taken into account? (e.g. if they subscribed >> "foo+mylist(a)example.com" but send the confirmation-reply from >> "foo(a)example.com", will that still work? > > > Yes. Only the token is required. > cool thanks. together with the not-yet-expired tokens, i think i can create some ad-hoc web-service that translates URLs to confirmation replies. mfd IOhannes

3 years, 3 months

[MM3-users]Re: Sass and where to find core rest logs

by Simon Hanna

On 05/05/2016 04:15 AM, Mark Sapiro wrote: > On 05/04/2016 09:45 AM, Andrew Hodgson wrote: > >> Anyway, I have compiled Mailman3, and the web interface is coming up. Bringing up the list of lists initially gave me an exception, and I saw a 5xx error in the mailman.log file in /opt/mailman/var/logs. I read up on this and as a result downgraded Falcon<1.0 in the Python 3.4 venv. >> >> I am still unable to browse the list of lists with a 500 error, only this time I am not getting an entry in the mailman.log indicating there is an issue, and I am wondering if there are more detailed logs that can be switched on? > > > There are the web server logs and there is the mailman-web configured in > LOGGING:handlers:file in (using bundler) > mailman-bundler/mailman-web/production.py (or testing.py). The > production default is /var/log/mailman-web/mailman-web.log; the testing > default is /opt/mailman/var/mailman-web/hyperkitty.log. > You might also get a 500 error because of a django error. If you have debugging enabled, you should see the trace in the browser. If not, then you should get an email (If you configured am admin email) Otherwise the files above should contain information about it. > >> The other question I have is on Sassc. I believe the default Mailman web interface has now switched to the Ruby implementation of Sass, but is this correct? The documentation on the Mailman-Bundler site seems to suggest that Sassc is still the default. > > > I think the bundler doc is out of date on this. > Hyperkitty switched from less to sass. Which sass compiler you use is irrelevant. You can use the ruby implementation (but it pulls in ruby as a dep). I am using the C preprocessor from libsass.org I will go over the docs and see if that section is unclear.

9 years, 1 month

[MM3-users] Re: re-sending confirmation mails (was Re: Re: pending subscriptions lost?)

by Andreas Barth

* Mark Sapiro (mark(a)msapiro.net) [220315 22:18]: > On 3/15/22 12:22, IEM Network Operation Center (IOhannes m zmölnig) wrote: > >yes. > >the *current* template. > >but not the template that came with mailman3 3.2.1 > > Which is over 3 years old. > > You should really be taking up these issues with Debian. Maybe if > they got enough pressure from users, they would update their > package. Debian (as all distributions) freezes their packages when releasing, that's why it's called stable. If someone wants newer packages, it's possible to use stable-backports (see below). Debian oldstable has mailman3 version 3.2.1. Debian stable has mailman3 version 3.3.1. So, in this case, the version in Debian oldstable is used. Which is, well, a bit behind stable, because oldstable is one release behind from the current stable. From (any) software point of view, distributions are always too old. However, having a frozen version of packages has great benefits for admins and reduces efforts. That's why distributions exists. As I said multiple times (also here), my recommendation is: if the software in the distribution works for you, use it. If not, use your own. However, don't assume that pressure works here at all - distributions are freezing packages for very good reason. As Debian is an volunteer effort, however it is always possible to help the distribution and get what you want by that. A good way is stable-backports, because this allows the admin to select to have single packages from the more current testing branch of Debian. However, this only happens if someone does the necessary handholding. So far nobody volunteered for mailman, therefor mailman isn't in stable-backports. If I'd like to have a current mailman on Debian, that would be my path forward (together with running Debian stable, not oldstable); but that's not an easy one if you are not involved with debian yet. Andi

3 years, 3 months

Search results for query "sapiro"