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

[MM3-users] Re: Random characters in "The results of your email commands" e-mail

by Mark Sapiro

On 2/17/20 3:00 AM, Jeffrey D wrote: > Hi, > > Today I sending an e-mail to "mylist-request(a)domain.tld" with the subject "help" and I received the expected e-mail with the following content; > > confirm - Confirm a subscription request. > echo - Echo back your arguments. > end - Stop processing commands. > help - Get help about available email commands. > join - Join this mailing list. > leave - Leave this mailing list. > stop - An alias for 'end'. > subscribe - An alias for 'join'. > unsubscribe - An alias for 'leave'. > No such command: -- > No such command: vriendelijke > > Only I think my mail signature broke something in Mailman (see the No such command). Something may be broken, but it was not your email command with signature that broke it. Mail to the -request address processes the Subject: as a command if it appears to be one and then processes each of the first several (default 10) lines of the body as a command until it encounters a 'stop' or 'end' command or other command whos process says don't continue. In this case your signature was reported as no such command. This is normal and expected. > Because every e-mail with a subject like "help", "stop" or "join", gives a reply with random characters. The Mailman logs doesn't show any error, so I'm not sure what is wrong. Deleting the mailinglist and create a new one won't fix the issue, also restarting Mailman doesn't help. > > An example of the random characters: > Nzzf&ju[zZ0:v,jzkb^}nJyazZCj}{m5t5Cx<{iysG5o[w}jgn+g[lrwf*mzrLk)rjwliazZZnjyW(fvrh{aXXWj+&j)b b-'jX+zwl&v{rx &~y6.r(fu4:' > > Is this a bug in Mailman? Or something in my Mailman config... To understand what's going on, We would like to see the complete, raw response message. Also, the headers of the message sent to the -request address, in particular the Content-Type: header of the first text/plain part and its charset param. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 2 months

[MM3-users] Re: Installing mailman 3

by Rafael Mora

I'm looking in /var/etc/mailman.log but nothing occurs and in the postfix maillog nothing occurs as well Is it possible to look into another config or log file? Thanks El mar., 1 ago. 2017 a las 13:02, Mark Sapiro (<mark(a)msapiro.net>) escribió: > On 8/1/17 10:15 AM, Rafael Mora wrote: > > Hello, > > > > I got postfix installed and I can use the command mail to send emails. > The > > thing is that mailman can't send the confimation mail yet, where should I > > look for the error?? > > > Look in Mailman's logs and Postfix's 'maillog'. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- Atentamente / Best Regards Ing. Rafael Mora

8 years, 9 months

[MM3-users] Re: New releases

by Abhilash Raj

On Thu, Jun 25, 2020, at 10:35 PM, Abhilash Raj wrote: > > > On Thu, Jun 25, 2020, at 8:59 AM, Danil Smirnov wrote: > > The issue has confirmed by other users: > > > > https://github.com/maxking/docker-mailman/issues/382 > > The issue seems to happen because the static files that are present at > the default staticfile locations aren't valid anymore and aren't > removed automatically on upgrades. > > You can run: > > sudo rm -rf /opt/mailman/web/static > > To remove them manually and then it should be re-created properly on > the next start. I'll try to work on a fix for this in some automated > fashion. Seems like I wasn't using the right options like Mark pointed out above. --clear flag will automatically remove the old files. I have created a PR[1] to fix it and will try to get it out with a new release soon. [1]: https://github.com/maxking/docker-mailman/pull/384 > > > > > вт, 9 июн. 2020 г., 20:49 Mark Sapiro <mark(a)msapiro.net>: > > > > > On 6/9/20 10:31 AM, Danil Smirnov wrote: > > > > On Tue, 9 Jun 2020 at 20:23, Mark Sapiro <mark(a)msapiro.net> wrote: > > > > > > > >>> COMPRESS_OFFLINE = True > > > >>> COMPRESS_ENABLED = True > > > >> > > > > > > > > These two are commented out. > > > > > > > > > Then compress shouldn't be trying to do anything. I can't explain what's > > > going on. > > > > > > -- > > > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > > > San Francisco Bay Area, California better use your sense - B. Dylan > > > _______________________________________________ > > > Mailman-users mailing list -- mailman-users(a)mailman3.org > > > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > > > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > > > > > _______________________________________________ > > 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) -- thanks, Abhilash Raj (maxking)

5 years, 10 months

[MM3-users] Re: How to configure mailman3-web

by Mark Sapiro

On 6/14/22 10:19, robert.winkler(a)bioprocess.org wrote: > Hi, I just installed mailman3-web on my Ubuntu 20.04 LTS web server. By Mailman3-web, I assume you mean the Debian/Ubuntu package. If so, your primary support resources are Ubuntu and Debian. > Port 8001 is open, the service is running: > > root@localhost:/etc/mailman3# systemctl status mailman3-web.service > ● mailman3-web.service - Mailman3-web uWSGI service > Loaded: loaded (/lib/systemd/system/mailman3-web.service; enabled; vendor preset: enabled) > Active: active (running) since Tue 2022-06-14 17:05:06 UTC; 47s ago > Docs: file:///usr/share/doc/mailman3-web/README.rst > Main PID: 30135 (uwsgi) > Status: "uWSGI is ready" > Tasks: 10 (limit: 2306) > Memory: 147.7M > CGroup: /system.slice/mailman3-web.service > ├─30135 /usr/bin/uwsgi --plugin python3 --ini /etc/mailman3/uwsgi.ini > ├─30152 /usr/bin/uwsgi --plugin python3 --ini /etc/mailman3/uwsgi.ini > ├─30153 /bin/sh -c python3 manage.py qcluster > ├─30155 python3 manage.py qcluster > ├─30158 python3 manage.py qcluster > ├─30159 python3 manage.py qcluster > ├─30160 python3 manage.py qcluster > ├─30161 python3 manage.py qcluster > └─30162 python3 manage.py qcluster > > Jun 14 17:05:05 localhost systemd[1]: Starting Mailman3-web uWSGI service... > Jun 14 17:05:05 localhost uwsgi[30135]: [uWSGI] getting INI configuration from /etc/mailman3/uwsgi.ini > Jun 14 17:05:06 localhost systemd[1]: Started Mailman3-web uWSGI service. > > in /etc/mailman3/mailman-web.py I changed localhost for my domain:port: > > MAILMAN_REST_API_URL = 'http://meteomex.com:8001' > POSTORIUS_TEMPLATE_BASE_URL = 'http://meteomex.com:8001/mailman3/ > > and restarted the service. > > on the server side, it looks fine, the mailman3 DB in postgresql exists. > > However, I cannot access the web interface, trying, e.g. > http://meteomex.com:8001/mailman3/ > 'http://meteomex.com/mailman3 > 'http://meteomex.com:8001 > > anything I am missing? E.g. concerning the Apache config? You should not be accessing port 8001 directly. Mailman core's REST API listens on port 8001 and Postorius is the one that accesses that API. uWSGI normally listens on port 8000 and Apache proxies to uWSGI on that port. What happens when you go to http://meteomex.com/mailman3? In order to say more, we would probably need to see your uWSGI configuration and the relevant parts of your Apache configuration -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 10 months

[MM3-users] Re: Prototype import [was: Re: Setup Question: Disk-Layout (Migrating from Mailman 2.1)]

by Mark Sapiro

On 4/19/25 1:55 PM, Mihai Moldovan wrote: > > This eventually led me to realize that passing > mailman.email.message.Message as the factory to mbox() internally calls > factory(msg), and the base class of Message (email.message.Message) has > an __init__ function that takes the policy parameter, so it looks as if > it's registering the mailbox message incorrectly as the policy handler, > which is totally wrong of course. This appears to be a bug in mailbox.mbox. To work around it, try this: ``` from email import message_from_bytes mb = mbox(sys.argv[2], create=False) for key in mb.iterkeys(): msg = message_from_bytes(mb.get_bytes(key), Message) ``` > and indeed, if I let the import actually happen, it works. Still, it's probably better if the message is a mailman.email.message.Message object rather than an email.message.Message object. > The imported messages, do have a Message-ID-Hash, but the Archived-At > and List-Archive headers are empty (literally <>). Those headers are added by the rfc_2369 handler based on the archivers configured for the list. They will never point to the prototype archiver or the message in the prototype archive. Normally they will point to HyperKitty and to the archived message in HyperKitty. This is the case even for messages in the prototype archiver as those messages are just the message as delivered to the list members absent any personalization. > Do you have an example message that was archived through Prototype? What > are the proper header values for this module? I believe that Archived-At > should be the Message-ID-Hash and the List-Archive header contain... > well, given that the Prototype archiver is not meant to be publicly > available, probably a file:// URL? Typically they will be something like List-Archive: <https://example.com/archives/list/listname@example.com/> Archived-At: <https://example.com/archives/list/listname@example.com/message/xxxxxx/> where xxxxxx is the message-id hash value. Note that the generation of these headers by the rfc_2369 handler depends on this script being run in an installation that has hyperkitty and mailman-hyperkitty installed and the hyperkitty archiver enabled for the list. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year

[MM3-users] Re: Issues with international characters (replaced by ?) when mail is send as text/html

by Mark Sapiro

https://gitlab.com/mailman/mailman/-/issues/967 is now fixed. This is the patch to fix it. See https://gitlab.com/mailman/mailman/-/merge_requests/946 ``` diff --git a/src/mailman/handlers/decorate.py b/src/mailman/handlers/decorate.py index ec0ba8ed385e529b2b4c959e41d7d8985cc783e5..53ea861de13c76d1571c3664ec8358bf9c97b4e0 100644 --- a/src/mailman/handlers/decorate.py +++ b/src/mailman/handlers/decorate.py @@ -18,13 +18,13 @@ """Decorate a message by sticking the header and footer around it.""" import re +import copy import logging from email.mime.text import MIMEText from email.utils import formataddr from mailman.archiving.mailarchive import MailArchive from mailman.core.i18n import _ -from mailman.email.message import Message from mailman.interfaces.handler import IHandler from mailman.interfaces.mailinglist import IListArchiverSet from mailman.interfaces.template import ITemplateLoader @@ -176,26 +176,12 @@ def process(mlist, msg, msgdata): # Because of the way Message objects are passed around to process(), we # need to play tricks with the outer message -- i.e. the outer one must # remain the same instance. So we're going to create a clone of the outer - # message, with all the header chrome intact, then copy the payload to it. - # This will give us a clone of the original message, and it will form the - # basis of the interior, wrapped Message. - inner = Message() - # Which headers to copy? Let's just do the Content-* headers - for h, v in msg.items(): - if h.lower().startswith('content-'): - inner[h] = v - inner.set_payload(msg.get_payload()) - # For completeness - inner.set_unixfrom(msg.get_unixfrom()) - inner.preamble = msg.preamble - inner.epilogue = msg.epilogue - # Don't copy get_charset, as this might be None, even if - # get_content_charset isn't. However, do make sure there is a default - # content-type, even if the original message was not MIME. - inner.set_default_type(msg.get_default_type()) - # BAW: HACK ALERT. - if hasattr(msg, '__version__'): - inner.__version__ = msg.__version__ + # message, with all the header chrome intact, then delete unwanted headers. + inner = copy.deepcopy(msg) + # Which headers to keep? Let's just do the Content-* headers + for h, v in inner.items(): + if not h.lower().startswith('content-'): + del inner[h] # Now, play games with the outer message to make it contain three # subparts: the header (if any), the wrapped message, and the footer (if # any). ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 3 months

[MM3-users] Re: Reply w/Email Clients - From: vs. Reply-To:

by Mark Sapiro

On 11/17/20 2:34 PM, j(a)manygoodideas.com wrote: > I'm setting up a new list, and a number of new list members are reporting a problem with replying to the thread. Their email clients seem to ignore the Reply-To: field and instead use from From: field. Are you saying that a 'reply' , not 'reply-all' will reply to the From: only and ignore Reply-To:? If so, the email clients that are doing that are badly behaved. I can't say they are non-compliant as RFC 5322 <https://www.rfc-editor.org/rfc/rfc5322.html#section-3.6.2> only says: The originator fields also provide the information required when replying to a message. When the "Reply-To:" field is present, it indicates the address(es) to which the author of the message suggests that replies be sent. I.e., Reply-To: is only a 'suggestion', but well behaved clients will follow it. > When they use Reply All, the email is addressed to both the From: and Reply-To:. Reply All should reply to the Reply-To:, To: and Cc: addresses and to From: if there is no Reply-To:. Whether Reply All should include From: if there is a Reply-To is not well defined. > Reading through previous threads here, I've tried a number of things: > > 1) DMARC mitigation action is "Replace From: with list address" > 2) For Alter Messages - Set "Reply goes to list" > > The goal is that we want a reply to go to the list, not the person posting. Since Reply-To seems to be ignored by some clients, I'm hoping there's a way to force the "From" field to become the list address. Thanks in advance for your suggestions! If Alter Messages -> Reply goes to list is set to Reply goes to list, Reply-To: will include the list posting address. What are the clients that ignore this? Complaints should go to the providers of those. Tf DMARC mitigation action is "Replace From: with list address", that will happen to messages to which DMARC mitigation action applies. If you want it to apply to all messages, set DMARC Mitigate unconditionally to Yes. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 5 months

[MM3-users] Re: Mail control not given from Mailman 3 to postfix

by Mark Sapiro

On 7/6/20 11:07 PM, Shashikanth Komandoor wrote: > > Recently I observed a peculiar case. There is a list say > testlist(a)lists.testdom.com has a non member say testuser(a)testdom.com whose > Moderation attribute is set to "Accept immediately (bypass all other rules). > > This testuser(a)testdom.com has sent a mail to testlist(a)lists.testdom.com > and postfix of my Maliman 3 received the request and handed over to Mailman > at 0.0.0.0:8024 socket running on the same machine and the same is logged > in /var/log/maillog. So it was received by Postfix and delivered to Mailman. > Since the user has the moderation attribute set to Accept, the > /var/lib/mailman/mailman/var/logs/vette.log also displayed "ACCEPT" on > searching with the same message id. And the post was accepted. (Apparently you override the path for logging.vette in your mailman.cfg since the default logs these to mailman.log) > At this point, to my expectations, there should be 2 entries for this > message id in smtp.log one for smtp and one for post. But I don't find any > log records with this message id in smtp.log and of course the mail is not > delivered even. You don't find the message-id in the smtp.log for the incoming LMTP because the message-id is not logged in this entry. It only logs the actual LMTP commands and the envelope sender and recipient(s). You don't find the <messageid> post to testlist(a)lists.testdom.com ... and <message-id> smtp to testlist(a)lists.testdom.com for nn recips, ... entries because the post never got to that point in the processing (those are logged when the post is delivered to the list members). > Could you please help me out if I have missed any point or improperly > understood the mail flow while using the mailman 3? There was probably some exception in processing causing the message to be shunted. If so, the message is in the shunt queue and there is an entry in mailman.log for the exception and shunting with a traceback from the exception which will help in diagnosing the reason. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 10 months

[MM3-users] Re: {Spam?} Re: Installation Wooes

by Mark Sapiro

On 5/4/20 11:07 AM, Samir Faci wrote: > The only way I've gotten it to work so far is by using the FQN. I can > switch back to 127.0.0.1 but that wasn't working. > > Here's the configuration I have. > > incoming: mailman.mta.postfix.LMTP > outgoing: mailman.mta.deliver.deliver > smtp_host: 127.0.0.1 > smtp_port: 25 > smtp_user: > smtp_pass: > > lmtp_host: 127.0.0.1 > lmtp_port: 8024 > > > > and the end result: > > https://gist.github.com/safaci2000/b1c91f936df1c0d5668250cf1d503494 which includes May 4 17:50:09 lists postfix/lmtp[2600677]: connect to lists.domain.org[198.199.98.177]:8024: Connection refused So the question is, why is Postfix trying to connect to lists.domain.org[198.199.98.177] and not to localhost[127.0.0.1] > smtp_host: 127.0.0.1 > lmtp_host: 127.0.0.1 > > #fail But it should work. > smtp_host: lists.domain.org > lmtp_host: lists.domain.org > > # success. And this should not be necessary. > The error I get if I don't open port 8024 is below and in the gist i linked > earlier. > > May 4 17:50:09 lists postfix/lmtp[2600677]: D98A21473D5: to=< > testing(a)lists.domain.org>, relay=none, delay=0.05, delays=0.03/0.01/0/0, > dsn=4.4.1, status=deferred (connect to lists.domain.org[198.199.98.177]:8024: > Connection refused) This is what is expected if port 8024 is not open and you are connecting to lists.domain.org. > The only way I've gotten it to work so far is by binding both the smtp_host > and lmtp_host to be lists.domain.org and opening up port 8024. > > I'd rather not have that port open but I'm open to suggestions on what else > to try. You need to get Postfix to use localhost[127.0.0.1] and not lists.domain.org[198.199.98.177]. One issue is when you change lmtp_host: lists.domain.org to lmtp_host: 127.0.0.1 you need to run `mailman aliases` to change the settings in var/data/postfix_lmtp. I think if you go back to smtp_host: 127.0.0.1 lmtp_host: 127.0.0.1 and run `mailman aliases`, restart mailman and reload Postfix, it should all work without opening port 8024 and probably without needing to put 198.199.98.177 explicitly in mynetworks in Postfix. I suspect you will have issues with mail not being accepted or treated as spam by some recipient ISPs however. See <https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS> -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years

[MM3-users] Re: anomalous behavior

by Mark Sapiro

On 10/5/24 04:14, donato(a)molino.it wrote: > Hi, > I installed mailman-full on debian 12. How? Did you follow https://docs.mailman3.org/en/latest/install/virtualenv.html or did you install the Debian packages. If the latter, please see https://wiki.list.org/x/12812344 > Everything works perfectly except for the fact that for a single ML the messages are not delivered to the recipients. > I have three MLs: > 1) example(a)example.com > 2) test(a)example.com > 3) hello(a)example.com > > For the n. 2 and 3 are fine, but 1 doesn't deliver. > The configurations are identical for all 3: > > smtp.log:Oct 05 11:37:44 2024 (42769) Peer: ('127.0.0.1', 37912) > Oct 05 11:37:44 2024 (42769) ('127.0.0.1', 37912) handling connection > Oct 05 11:37:44 2024 (42769) ('127.0.0.1', 37912) >> b'LHLO list.example.com' > Oct 05 11:37:44 2024 (42769) ('127.0.0.1', 37912) >> b'MAIL FROM:<subscriber(a)domain.tld> SIZE=7873 BODY=7BIT' > Oct 05 11:37:44 2024 (42769) ('127.0.0.1', 37912) sender: subscriber(a)domain.tld > Oct 05 11:37:44 2024 (42769) ('127.0.0.1', 37912) >> b'RCPT TO:<example(a)list.example.com>' > Oct 05 11:37:44 2024 (42769) ('127.0.0.1', 37912) recip: example(a)list.example.com > Oct 05 11:37:44 2024 (42769) ('127.0.0.1', 37912) >> b'DATA' > Oct 05 11:37:44 2024 (42769) ('127.0.0.1', 37912) >> b'QUIT' > I also enabled all debugging in mailman.cfg. > But everything is fine What's in the MTA log? Does list 1 have any non-digest members with delivery enabled `mailman members --regular --nomail enabled example(a)example.com` In addition to the above in smtp.log, I would expect to see entries similar to the following for your post to this list. ``` Oct 05 11:15:02 2024 (3390806) <172812689916.3390800.7261628565807094029(a)mail.mailman3.org> smtp to mailman-users(a)mailman3.org for 4 recips, completed in 0.31321239471435547 seconds Oct 05 11:15:02 2024 (3390806) <172812689916.3390800.7261628565807094029(a)mail.mailman3.org> post to mailman-users(a)mailman3.org from mailman-users-owner(a)mailman3.org, 5028 bytes Oct 05 15:22:57 2024 (3390806) <172812689795.412444.17509223827906057290(a)mail.mailman3.org> smtp to mailman-users(a)mailman3.org for 334 recips, completed in 52.519867181777954 seconds Oct 05 15:22:57 2024 (3390806) <172812689795.412444.17509223827906057290(a)mail.mailman3.org> post to mailman-users(a)mailman3.org from donato(a)molino.it, 1683 bytes ``` (the delay between 11:15:02 and 15:22:57 above is the time between arrival and held message approval) Do you see things like that? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 7 months

Search results for query "sapiro"