[Mailman-Users] Re: Mailman subscribe confirmation
On 2024-07-05 at 11:59:54 UTC-0400 (Fri, 5 Jul 2024 15:59:54 +) John is rumored to have said: Hello, We've encountered a weird issue with mailman 2. We're using mailman 2.1.39, running on a straight RHEL 9 server. When someone subscribes to a mailing list, they receive an email that says, among other things: Or visit this web page: http:///mailman/confirm//9e2fccef2ac047bb3d67e602e7fb695a277afe43<http://ourdomain.com/mailman/confirm/ourlist/9e2fccef2ac047bb3d67e602e7fb695a277afe43> Normally, clicking on this link would confirm the subscription. In our case, it prompts for the string again, and keeps doing so - it seems that mailman doesn't recognize the string as being valid. One thing to check is that URL. If your webserver always redirects http to https but Mailman thinks its URL starts with http:// you will have problems like this. The solution is switch Mailman to use the https URL. Using one of the other confirmation methods, such as just replying to the message, works correctly. The new subscriber is confirmed successfully. The same issue occurs for unsubscribe requests. The What steps are required for subscription? option is set to Confirm. Can anyone suggest how to fix this? Thanks. ::Jack -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: mailmanu-20190...@billmail.scconsult.com -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@jab.org
[Mailman-Users] Re: Delayed messages
On 2022-10-08 at 09:32:52 UTC-0400 (Sat, 8 Oct 2022 15:32:52 +0200) Christian via Mailman-Users is rumored to have said: Hello Robert Heller. On Sat, 8 Oct 2022 09:28:50 -0400 (EDT), you wrote: What sorts of e-mail addresses are delayed. Are *all* users seeing delays or only some (eg only people with @yahoo.com or @hotmail.com addresses?). It concerns all addresses - even those who are on the same server / same domain. Do you have access to your server's mail queue? Do you have command-line access to your server? No, unfortunately not. It is a cPanel installation on a virtual server. It is my understanding that Mailman only puts a message in the archive after it has handed off deliveries to the local MTA. cPanel historically (circa 2018) had queue run timings for Exim (the MTA) that were unfit for mailing lists. I know cPanel was made aware of the issue but I do not recall whether they pushed out a fix or just documented a configuration fix. You may not be able to change or even see the Exim config, since I believe cPanel manages Exim at the host-wide level (using WHM) which customers don't generally have access to. You should talk to your provider about how Exim is configured. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
[Mailman-Users] Re: Odd issue after setting Mailman to use https by default.
See https://wiki.list.org/DOC/4.27%20Securing%20Mailman%27s%20web%20GUI%20by%20using%20Secure%20HTTP-SSL%20%28HTTPS%29 Summary: set DEFAULT_URL_PATTERN to use https and run 'withlist -l -r fix_url " with every list. On 2022-06-21 at 11:39:49 UTC-0400 (Tue, 21 Jun 2022 15:39:49 +) Bruce Johnson via Mailman-Users is rumored to have said: Last week I got a notification from our SSL cert provider that the cert for our mailman server was expiring, so I renewed it, and realized that when I rebuilt the server last year I didn’t actually enable it in Apache. So I did, and added a rewrite rule in the httpd.conf to force all traffic to use https. After that, whenever a moderator or admin tried to submit a response for a held message, we would get a pop-up stating that “This form is insecure” , if we proceeded, the form submitted but nothing would happen…the message was not approved or discarded. After I removed the rewrite rule, the action works now, but it drops me onto the http:// site not https:// . Is there some site setting in Mailman I am missing to tell it to always use https:// ? (MM version version 2.1.29 running on Rocky Linux 8.5) -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
[Mailman-Users] Re: group mismatch
On 2022-05-16 at 12:32:54 UTC-0400 (Mon, 16 May 2022 18:32:54 +0200 (CEST)) Lucio Chiappetti is rumored to have said: On Sun, 15 May 2022, Jon Baron wrote: I am trying to use spamassassin by running everything through /etc/procmail, Sorru, I do not understand what procmail and spamassassin, intended to process INCOMING mail, have to do with mailman which is SENDING OUT mail. It is fairly common for SpamAssassin to be used on both incoming and outgoing mail, but obviously outgoing would need to use something other than procmail to call it. I still have a few almost-dead mailman lists on my machine, and I do use procmail to filter my personal incoming mail. It is a long time we have abandoned (been forced to abandon) spamassassin, but that was running on the institute MX, not on my own machine. As far as I remember (after a first trial) spamassassin was run as a milter in sendmail.cf (the sendmail doc had s[pecial instructions). SpamAssassin can be used as a milter during the SMTP transaction or as a filter in the delivery pipeline via a delivery agent like procmail. Using procmail is generally suboptimal, but it may be the only mechanism available for an end user to deploy SA for their own mail without root access. Also: procmail is antique abandonware that no one should use in 2022, but it can be very hard to replace. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
[Mailman-Users] Re: Plus addressing
On 2022-03-21 at 10:01:58 UTC-0400 (Mon, 21 Mar 2022 14:01:58 -) is rumored to have said: Does the list support plus addressing? What do you mean by that question??? "Plus addressing" is only relevant to final local delivery and in some cases to intra-realm bespoke mail routing. Address local-parts MUST NEVER be interpreted as anything but opaque nonces unless they are in "your" domains. Do not attempt to parse, validate, translate, or canonicalize local-parts in other people's domains. A mailing list MUST NOT generically equate two local-parts in a non-local domain without the explicit permission of the users whose addresses are being equated. Google and O365 support plus addressing. That is not relevant to a mailing list not operated by Google or MS. Support for plus-addressing has been widespread for decades. If it isn't YOUR plussed address, it's just an address. The plus in the local part is none of your business. Do not touch it. You cannot know how an address owner is handling plussed addresses unless they tell you, and that does not mean unless their mail provider tells you. This allows someone to subscribe as myself+li...@mycompany.com when their real email address is mys...@company.com. Yes. I do something similar and have for decades. Every list I subscribe to uses a different address, all of which ultimately deliver to mailboxes in the same IMAP account. I abandoned the '+' as a delimiter some years ago because of the bad habit of some mail handlers of trying to disassemble plussed addresses. The problem is that when they reply, or generate a new message, it may be held or rejected because it is coming from an address different than they subscribed with. That is 100% the sender's problem. If they can't send and receive mail with the address they used to subscribe, they should never have used it to subscribe. It's fine to accommodate specific individuals' incapacity to use their addressing flexibility as designed. If a MUA doesn't support sending mail with arbitrary plus addressing, it doesn't really support plus addressing. That includes webmail MUAs like GMail and MS365/OWA. Desktop MUAs have been supporting this since Eudora v1.0, so it's hardly a novel feature. I am aware of the hack at: https://wiki.list.org/DOC/How%20can%20I%20post%20from%202%20or%20more%20addresses%20to%20a%20%22members-only%22%20list%3F However this does not appeal to the tinfoil hat crowd who thinks you are just going to sell both addresses. Nor do I want to explain to the masses this hack. The only reason to do that is to accommodate individuals who specifically want it and/or who chronically send with a wrong address and so clearly need it. The idea of a discussion mailing list 'selling addresses' is silly. Without significant customization any subscriber to a discussion mailing list using Mailman or similar tools can see the address of every person posting to the list. If one uses an email address in a public way for long enough, it will get to spammers. Even if you don't use it publicly, spammers may land on it with guesses and other users might typo their addresses to yours when giving it to others. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
[Mailman-Users] Re: Plus addressing
On 2022-03-22 at 03:23:29 UTC-0400 (Tue, 22 Mar 2022 08:23:29 +0100) Christian via Mailman-Users is rumored to have said: Hello robertowenbere...@gmail.com. On Mon, 21 Mar 2022 14:01:58 -, you wrote: Does the list support plus addressing? Google and O365 support plus addressing. This allows someone to subscribe as myself+li...@mycompany.com when their real email address is mys...@company.com. The problem is that when they reply, or generate a new message, it may be held or rejected because it is coming from an address different than they subscribed with. Instead of using "Plus addressing", in most (if not all) mail programs it is possible to set up rules for messages coming from a certain source. This rule can sort messages from mailinglist1 in one mail folder, and messages from mailinglist2 in another folder. And sometimes users use plus addressing (or other related 'tagging' schemes) to support such rules. Of course, that's not the business of a mailing list operator. We should assume that our users know what they're doing and that it isn't our business unless they need help. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
[Mailman-Users] Re: max value of mailman2
On 2022-02-15 at 04:19:31 UTC-0500 (Tue, 15 Feb 2022 09:19:31 -) kukyayuni--- via Mailman-Users is rumored to have said: Hi I would like to know the MAX values listed below for mailman2. Is there any document that explains them? The best place to look for Mailman2 answers is wiki.list.org. Such as: https://wiki.list.org/DOC/What%20is%20the%20largest%20list%20Mailman%20can%20run%3F? Is there a limit to the number of mailing lists that can be created in mailman2? What is the maximum number of recipients that can be registered to a single mailing list created by mailman2? See the above link. It describes a number of cases of lagre Mailman2 deployments. There are no arbitrarily-imposed limits on the number of lists or the number of users per list. You can run into serious performance problems as the number of list members increases, due to the way Python 'pickle' files are used. If you throw enough memory, fast enough storage, and enough cpu cores at Mailman, it can scale to hundreds of thousands of users and hundreds of lists, but you may not be pleased with the resources required to get good performance at scale. Mailman is designed for discussion lists more than it is for high-volume announcement/marketing lists. It takes significant MTA and backend tuning to mail more than a few thousand users in a reasonable amount of time, and Mailman is not always the right choice for that. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
[Mailman-Users] Re: Should CSRF check disregard case of addresses?
On 2021-12-13 at 13:02:22 UTC-0500 (Tue, 14 Dec 2021 03:02:22 +0900) Stephen J. Turnbull is rumored to have said: Mailman-admin writes: Am 13.12.21 um 12:09 schrieb Sebastian Hagedorn: Nov 24 19:33:24 2021 (117276) Form for user x...@smail.uni-koeln.de submitted with CSRF token issued for x...@smail.uni-koeln.de. The only difference is in the case of the email address. I’m no expert on CSRF attacks, but to me it seems as though the comparison should perhaps disregard differences in case only? As local part of an email address can be case sensitive, This is true, but this should only be case insensitive for the domain part. [...] So this is potentially very complicated. Case-squashing domain parts? Not complicated. Simple. The hardest part is handling IDN, which is not in fact all that hard. The only utility in mixed-case domain names is for human readability and the non-standard trick that uses case preservation as a means of detecting DNS hijacking. The bottom line on that trick is that only DNS servers should care about preserving domain name case. Also simple: NEVER try to interpret or canonicalize local-parts that exist in someone else's domain. You cannot programmatically determine whether 2 different local-parts are equivalent unless you run the delivery system for them. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
[Mailman-Users] Re: Highlighted text disappears
On 28 Mar 2021, at 15:11, Vako Nicolian wrote: I already know the answer that this has nothing to do with mailman, but I want your opinion: When members send emails that are highlighted, we receive it ok, but when people reply or forward the same email, the highlight is gone. I tested with the same users sending them private emails (outside of mailman) and it all works ok. Any idea why if we use mailman, the highlight disappears? is it a settings issue? I am doing the same highlight here to see if it will work for this group. "Highlighting" is a function of non-plaintext email, most often HTML in the modern world but also sometimes other proprietary formats (e.g. older Outlook) or other "rich text" formats that have lost the competition to HTML, such as the "text/enriched" format. Most mail composers using HTML in email use a "multipart/alternative" structure which includes both a HTML version of the message and a plaintext version, so that mail readers can display the mail even if they do not support HTML. For a variety of reasons, some mailing lists are configured to strip out the HTML part of multipart/alternative messages. Many users (including myself) also preferentially only display the plaintext version of multipart messages and so only reply to what is in that part. Because any "highlighting" is only present in non-plaintext email, lists and users who stick to plaintext do not see or preserve that highlighting. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
[Mailman-Users] Re: CPU %-usage surge associated with list archives
On 16 Nov 2020, at 2:17, Stephen J. Turnbull wrote: Bill Cole writes: On 15 Nov 2020, at 22:18, Stephen J. Turnbull wrote: I don't see why access to archives would cause a security issue, Thanks for the reply! Also FWIW, I'm explaining here why I don't think this is a Mailman issue. If there is a vulnerability in our distribution, and the SELinux policy is pointing it out, we (I think I speak for all the core devs here ;-) want to fix it. Right. I agree that it is not a problem with anything Mailman is doing that is in any way dangerous or even that it is something that the base distribution should attempt to deal with. FWIW: 1. SELinux doesn't know about specific security issues, it assumes that nothing is safe unless explicitly allowed. Yes, I was already aware that that is the "theoretically correct" policy, and had guessed that SELinux follows it. 2. On RHEL7 and its derivatives, the default SELinux policy includes a module for mailman's executable and data files which *in my experience* just works without modification when mailman is installed from an official RPM. Aha. Now *that* is *very* useful information! So I assume that would also apply to sufficiently recent CentOS, and most likely to Fedora. Yes. And it's something to look up on Debian and Ubuntu. It seems that https://github.com/SELinuxProject/refpolicy is the upstream basis for the EL-family default policy and it appears to have build switches for other lineages. I believe that the EL family is the only one that has SELinux enabled and enforcing by default. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
[Mailman-Users] Re: CPU %-usage surge associated with list archives
On 15 Nov 2020, at 22:18, Stephen J. Turnbull wrote: I don't see why access to archives would cause a security issue, FWIW: 1. SELinux doesn't know about specific security issues, it assumes that nothing is safe unless explicitly allowed. 2. On RHEL7 and its derivatives, the default SELinux policy includes a module for mailman's executable and data files which *in my experience* just works without modification when mailman is installed from an official RPM. It's even documented, if the policy docs are installed: # apropos mailman |grep selinux mailman_cgi_selinux (8) - Security Enhanced Linux Policy for the mailman_cgi processes mailman_mail_selinux (8) - Security Enhanced Linux Policy for the mailman_mail processes mailman_queue_selinux (8) - Security Enhanced Linux Policy for the mailman_queue processes It would certainly be possible to break that by assigning the wrong SELinux labels to the mailman files, perhaps by installing from the unpackaged source. Fixing that sort of error is probably simple, but it would depend on what specifically was done. A simple 'restorecon -Rv /' will fix a lot of issues, but it isn't instantaneous and stomps on any customization that hasn't been written into the persistent policy. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
[Mailman-Users] Re: mailman v2.x
On 19 Sep 2020, at 8:39, Stephen J. Turnbull wrote: As far as I know there are already obvious security holes in Python 2 if you need to use TLS, especially on Mac. Python 2 is not up to current security recommendations with respect to SSL and TLS versions, and I suspect not with respect to other basic crypto. I don't think it's hard to configure those version exclusions, but it doesn't come out of the box that way. And on Mac you've got the mess that is an Apple-specific TLS API that Python doesn't have a wrapper for last I heard (it uses an bundled version of OpenSSL instead if you configure it to support TLS). That's a pretty obscure edge case. Most people who use *current* MM2 on Mac do so via Homebrew or MacPorts builds, both of which also bring in a current OpenSSL by default. If one insists on building from scratch using the system "openssl," then on any recent system it is actually a recent and reasonably safe LibreSSL. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently) -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
[Mailman-Users] Re: Problem running CGI - Mailman Admin UI
On 23 Jul 2020, at 7:40, Odhiambo Washington wrote:
Hello List Admins,
I am somehow at the end of my thinking capacity with this problem, yet
I
think it's something minor that a third eye can help me with:
I have installed mailman-2.1.34 on a brand new box running
FreeBSD-12.1.
The problem is that the web UI won't open. It instead prompts me
to download a file. The contents of the file can be seen from the
below
link:
https://pastebin.com/8bh6g6rv
That's the 'listinfo' ELF binary. That indicates a webserver
misconfiguration: it's sending what it should be executing.
How I have done the installation:
1. I did the manual options
cd mailman-2.1.34
./configure --with-cgi-gid=80 --with-mail-gid=26
make
make install
Have you considered the options of installing the prebuilt package or
from the ports tree? Either may work for you without any fuss.
2. The files in /usr/local/mailman:
[...]
drwxrwsrwx 22 root mailman512 Jul 29 2017 mailman
Probably unrelated, but that's very disturbing.
[...]
VirtualHost configuration:
Ok, this is for http://whatever...
ServerName lists.mydom.ain
ServerAdmin odhia...@gmail.com
ErrorLog /var/log/mailman-error.log
RewriteEngine On
# RedirectPermanent /mailman/ https://lists.kictanet.or.ke/mailman/
RewriteRule ^/(mailman|pipermail|icons|htdig)/.+$ - [S=1]
RewriteRule ^/(mailman|pipermail|icons|htdig)(/.*)
https://%{HTTP_HOST}/$1$2$3$4
[L,R]
That kicks you over to a port 443 virtual host.
RedirectPermanent /htdig /icons/htdig
RedirectMatch ^/mailman[/]*$ /mailman/listinfo/
Alias /pipermail "/usr/local/mailman/archives/public"
Options Indexes FollowSymlinks
AllowOverride all
Order Allow,Deny
Allow from all
Require all granted
ScriptAlias /mailman/ /usr/local/mailman/cgi-bin/
This applies to the port 80 vhost. Do you have the same in your port 443
vhost?
Options FollowSymLinks ExecCGI
AllowOverride None
Order Allow,Deny
Allow from all
Require all granted
What is it that I am being blind to that makes the web UI not open?
My guess: no ScriptAlias directive in the port 443 vhost.
Thanking you in advance for being my third eye.
I hope the above qualifies...
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives:
https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/
Re: [Mailman-Users] The last release from the GNU Mailman project (was: Handling Munged From Addresses)
On 27 Feb 2020, at 14:24, Jim Popovitch via Mailman-Users wrote: Personally, I'd like to see the GNU Mailman project have a formal Mailman 2.3 release that supports Python3, I feel that there would be a lot of support for that. I'm sure there would be widespread applause and congratulations if such a thing were actually released. That sort of "support" is unhelpful towards actually making such a release. The needed support is the actual skilled effort of writing the required Python3 code. I don't have the time to hunt down the specific statements, but I have vague recollections that both Barry and Mark have said repeatedly that doing so would be substantially more effort than they are willing to put into anything built on the MM2 architecture. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] mailman 2.1.18 for RHEL 5
On 17 Feb 2020, at 5:27, Dennis Putnam wrote: On 2/16/2020 11:45 PM, Stephen J. Turnbull wrote: Dennis Putnam writes: Since migrating to mailman 3 on the latest RHEL is going to take some time, I need an interim solution to DMARC mitigation. I understand version 2.1.18 Why 2.1.18? Do you have that already installed? It's already pretty old, and many of the fixes still being made are security-related. It turns out that the only version available for RHEL 7 is 2.1.12. However, the mailman documentation indicates that also has DMARC mitigation. Anyway, I am giving it a try. Seems silly that RHEL repositories are so far behind the curve. RedHat has a policy of nailing down nominal versions of software with each major RHEL release and then backporting whatever fixes they deem important into their packages over the life of the major release, adding their own subordinate versioning. I know from working on the SpamAssassin security team that RH is particularly attentive to security issues and other major bugfixes. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently) -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Apache subscription Referer rules
On 10 Jan 2020, at 10:52, Jim Popovitch via Mailman-Users wrote: (I think I asked this a few months back, but I couldn't locate any emails on it) What is the Apache rule syntax for rejecting subscription linking that doesn't come from the same domain/site? First step: Header always set Referrer-Policy "same-origin" This assures (to the degree that browsers comply with directives provided in headers) that legitimate internal links and sub-resource loads have a Referer header (see https://en.wikipedia.org/wiki/HTTP_referer) which you can use. The next step is to read https://httpd.apache.org/docs/2.4/rewrite/access.html#blocked-inline-images and adapt the example to your site. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently) -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] mailman not functional
On 17 Oct 2019, at 16:41, Steven Jones wrote: ssh takes a long time to login but there is no load to cause this. The first thing to suspect when logins take a long time with no tangible loading issues (i/o, memory, and CPU all good) is DNS. If your resolver is trying to query a non-responsive DNS server or servers but eventually hits one that works, login and anything involving email transport will be plagued by delays. So: check /etc/resolv.conf and make sure all listed servers are responding to queries. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] messages fail to @yahoo @aol @outlook
On 28 Jul 2019, at 13:04, Jayson Smith wrote: Hi, The problem I'm familiar with is messages *from* AOL/Hotmail/Yahoo/etc. being rejected by other Email providers. It happens in both directions. Providers who publish a "p=reject" DMARC policy typically also honor other providers' "p=reject" DMARC policies. If a mailing list makes any change to messages, it should also either munge From or wrap messages to avoid problems. You can do that for all messages, only for "p=reject" sender domains, or for both "p=reject" and "p=quarantine" domains. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] messages fail to @yahoo @aol @outlook
On 28 Jul 2019, at 11:25, Loren Engrav via Mailman-Users wrote: > and searched archives > and see this goes back years and years > is there a quick fix I missed in the archives? This looks like a DMARC problem. See https://wiki.list.org/DEV/DMARC -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Trying to secure the list server web page
On 27 Feb 2019, at 11:58, Mark Sapiro wrote: On 2/27/19 8:48 AM, Jeffrey Westgate wrote: Confession first -- I touch this server so seldom because it just runs... and I inherited it many moon orbits ago. The setting I needed was actually in the Defaults.py, and not in the mm_cfg.py. And it was http. I did the change, pushed it out, and we're back in fine form again. First, never change Defaults.py. Put overrides in mm_cfg.py. See <https://wiki.list.org/x/4030588>. Also, for your original question, see all the steps at <https://wiki.list.org/x/17892007>. Also note: if you do this on a machine managed by cPanel, you will need to redo the last step ($prefix/bin/withlist -l -r fix_url) daily after the nightly maintenance cron job, which reverts whatever fix_url does. There is an open bug at cPanel (opened last week) to fix that. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Available For Hire: https://linkedin.com/in/billcole -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] How to kill zombie pending moderator requests?
On 16 Feb 2019, at 12:55, Brian Carpenter wrote: Check the headers of the request to make sure it is not coming from your older server. That would have been best but the list owner was getting them, not me, and the messages were right there in the exim_mainlog on the cPanel machine... I run all of my clients' lists on cPanel servers and have done hundreds of migrations from other servers. So, this raises 2 questions: 1. Do you have or know of a complete documentation of how to migrate a Mailman list from a standard installation to cPanel? I did the migrations that spawned this problem as a pilot for dozens that need to be moved in the near future and wrote up the process that I used so that others should be able to follow it, but I'm not filled with confidence in the end result and would love to compare notes with someone who has it nailed down. 2. Most specifically, how do you deal with migrating pending moderator actions and subscription requests? I handled the lists I moved with declaring a subscription & config freeze (easy, since these are private lists) and asking the mods to clear all requests the morning of the move, but obviously that didn't quite work because spammers don't even try to pay attention to our change control discussions. The times that clients' reported phantom moderated notifications, all were coming from their previous server. Still batting 1.000 :) cPanel has great tools for monitoring list traffic btw. It is the main reason why I run all of my 2.1 lists on cPanel servers. I need to look more closely at those at some point. The company I'm doing this for mostly leaves all the list administration to their customer listowners, and I am a bit leery of presenting those not-so-technical folk with a whole new interface doing things they never knew they might have wanted. I have pared down a feature package for cPanel to make it reasonable to present them with a non-bewildering UI for managing via cPanel, but for now I'm just trying to make the migrations as painless as possible. Thanks for the help! -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Available For Hire: https://linkedin.com/in/billcole -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] How to kill zombie pending moderator requests?
On 16 Feb 2019, at 13:00, Mark Sapiro wrote: On 2/15/19 9:40 AM, Bill Cole wrote: I recently migrated a set of Mailman lists from a standard 2.1.18 installation (on ancient RedHat) to a cPanel host (CentOS 7) running Mailman 2.1.27. One glitch in that migration involves a pending moderation issue, which ultimately does not need to be dealt with because it was just spam to the list address from a non-member. Due to some flaw in my migration process (probably related to cPanel's list name mangling) the daily pending request reminder script is sending the moderator a reminder of the issue, however the issue is not visible in the web UI. The notice is coming from the old install. See <https://wiki.list.org/x/8683538>. I guess that I am not the first person to make this mistake. I had actually considered that, but since the notices were going to the list owner and I'm just the mail janitor^Wadmin and I could see them in the log on the new system, I ruled that out without actually getting the list owner trained on how to get headers out of Outlook... Of course, the reason they were in the log was that they were being sent to list-owner@ and further obfuscating matters, the old host was and still is the exterior gateway for mail inbound and outbound. My first impulse is to just clobber the pending.pck file, but I am not sure if that is safe. Advice would be greatly appreciated. It's safe, but it won't help for two reasons. The reminder is not coming from the cPanel Mailman, and the relevant file is requests.pck (moderator requests), not pending.pck (pending confirmations). Useful information! Thanks! -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Available For Hire: https://linkedin.com/in/billcole -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
[Mailman-Users] How to kill zombie pending moderator requests?
I recently migrated a set of Mailman lists from a standard 2.1.18
installation (on ancient RedHat) to a cPanel host (CentOS 7) running
Mailman 2.1.27. One glitch in that migration involves a pending
moderation issue, which ultimately does not need to be dealt with
because it was just spam to the list address from a non-member. Due to
some flaw in my migration process (probably related to cPanel's list
name mangling) the daily pending request reminder script is sending the
moderator a reminder of the issue, however the issue is not visible in
the web UI.
The pending.pck file for the list has this unilluminating content:
# ../../bin/dumpdb pending.pck
[- start pickle file -]
<- start object 1 ->
{ 'evictions': { 'fe643c3a29afd79686e7ee0578f83b2fa2ae1eba':
1550223270.461477},
'fe643c3a29afd79686e7ee0578f83b2fa2ae1eba': ('H', 2440),
'version': 2}
[- end pickle file -]
Python is not a language I use much so I'm not sure what the daily
'checkdbs' script is seeing that makes it think there's a pending issue
or what exactly the contents of that pending.pck means, although I
expect it is relevant. The other 3 lists that were migrated in the same
way at the same time which did not have pending issues have similar
pending.pck contents but DO NOT generate the phantom notifications.
My first impulse is to just clobber the pending.pck file, but I am not
sure if that is safe. Advice would be greatly appreciated.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Which user is harvesting sender emails?
On 19 Aug 2016, at 11:13, Jim Popovitch wrote: On Fri, Aug 19, 2016 at 11:01 AM, Bill Cole wrote: On 19 Aug 2016, at 10:39, Jim Popovitch wrote: PRVS/BATV How is that relevant to this issue? Well it's not, it's only relevant to what you and Mark were discussing (modification of From:) Ah, I see. I guess... However, BATV does NOT modify the From: header. It only replaces a local RFC5321.MailFrom address (a.k.a. bounce address, SMTP envelope sender, return-path) with another local address specific to that message. I merely provided an example of a popular in-use modification of From:, because you said "Please, don't anyone do that, ever.". My plea of prohibition only applies to replacing a RFC5322.From address (the "From:" *header*) which is not in the local administrative domain with some other locally-invented address which is also not in the local administrative domain without the affirmative informed consent of the owners of both addresses. That is particularly important in the context of a mailing list which broadcasts the invented addresses into a space that is known to return obnoxious mail to RFC5322.From addresses. This is a narrowly specific and jargoned-up case of a broad general rule: Don't invent and/or share addresses that belong to others without consent. -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Which user is harvesting sender emails?
On 19 Aug 2016, at 10:39, Jim Popovitch wrote: PRVS/BATV How is that relevant to this issue? BATV only applies to the envelope sender address, which any proper mailing list (including any Mailman list) completely replaces with its own bounce address so that bounces go to the mailing list software and not to the original sender or the list itself. As the OP said, this is someone or something spamming the original message authors (as shown in From headers) with the same Subject header as something they've posted to a list. -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Which user is harvesting sender emails?
On 18 Aug 2016, at 19:36, Mark Sapiro wrote: Altering the From: based on recipient can be done by modifying the code. Say you have a message "From: Ann User " and you want to change that to "From: Ann User " where xxx is a unique code for each recipient. Please, don't anyone do that, ever. It's not just "risky," as noted in earlier discussion, it would be positively abusive. A less obvious approach would be to add an address IN A DOMAIN YOU CONTROL in a X-[something] header (or perhaps a Cc header) that is unique to each recipient so that when you get mail to that address, you've identified your problem user. HOWEVER, there is an angle to this problem that should be understood: it's probably not being done by a human subscriber. One possibility is that a subscriber has malware on their machine that is generating the spam, so when you identify a subscriber who is your vector, you may only be identifying someone which an insecure machine. Another possibility (which would be untraceable and easy to automate on the spammer side) is that someone other than a subscriber is harvesting addresses and subjects from your web archive at mail-archive.com, where every message has a button to "Reply via email" that kicks back a redirection to a mailto: URL with the sender's address and Subject. -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Many users unsubscribed at once (not by me)
On 13 Dec 2015, at 13:56, Mark Sapiro wrote: In fact, the fact that almost all the unsubscribed users were hotmail makes it seem that this is not DMARC, but more likely hotmail (Microsoft) blocking the sending IP. And with the one other being live.com.au (roughly: Australian Hotmail) it becomes a distinctively Microsoft problem. For what it is worth, recently the policy staff and policies of Microsoft's former-Hotmail and former-Frontbridge have seemed to be converging/merging. One win for the world of this is that the chronic problem of Hotmail/Live.com mail being accepted but silently discarded has been replaced by overt rejection at the MX border (no, not THAT MX border) in many cases. For Mailman lists, one result is that long-dead addresses are getting cleaned out because they are now bouncing. Another result is that some silent discards have been replaced by delivery, so in some cases people who haven't seen mail from a list in years and now are seeing it and telling MS that it's spam. The second process can lead to broad blocking across MS-hosted domains, but at least now it is visible. -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] merging 2 mailing lists
On 7 Jul 2015, at 7:15, Laura Creighton wrote: In a message of Tue, 07 Jul 2015 00:33:00 -0400, "Bill Cole" writes: On 6 Jul 2015, at 9:26, Laura Creighton wrote: 2 somebodies I know want to merge their mailing lists. Have they bothered asking each and every subscriber and received an affirmative reply? No? Imagine my shock... The correct answer to this is "No, you can't. You don't have subscriber permission to do so." Unless you think having all of the IPs of the list service provider *correctly* blacklisted in many places is a good thing. ??? There's been major discussion about this on both lists, and everybody thinks it's a wonderful idea. Not a single objection. I am sorry. By way of explanation, it was late and I skimmed with tired eyes, missing the key point that these are traditional discussion lists rather than unidirectional broadcast lists. For a pair of active discussion lists, open discussions of a merger on-list is absolutely fair warning. -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] merging 2 mailing lists
On 6 Jul 2015, at 9:26, Laura Creighton wrote: 2 somebodies I know want to merge their mailing lists. Have they bothered asking each and every subscriber and received an affirmative reply? No? Imagine my shock... The correct answer to this is "No, you can't. You don't have subscriber permission to do so." Unless you think having all of the IPs of the list service provider *correctly* blacklisted in many places is a good thing. -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] What would your dream Mailman web interface look like?
On 6 Apr 2015, at 20:02, Andrew Stuart wrote: Sounds like not working with JavaScript is something important to you. What’s the thinking behind wanting to work without JavaScript? Isn’t it kinda hard to navigate the modern web without JavaScript? I don't know the original poster's motivations, but for me it is entirely practical. I work in a diverse variety of environments administering a complex menagerie of systems and Mailman is just one small piece of that. I frequently don't have a convenient modern GUI browser configured to my tastes/paranoias running on a network I trust, and it is actually more convenient for me to use a text browser with weak or no JS support (yes, really.) It is also an issue for user support, since users do work with the MM web interface from time to time. JS is an area where interop between browsers and the diverse ways users tweak them is at its worst. Supporting users who have found new ways for the MM web interface to not work because of JS subtleties sounds like at least the 6th ring of Hell. Also, sticking with a pure HTML client interface makes it easier to validate its security, e.g. a site with no scripts has no XSS vulnerabilities. MM isn't the sort of web application that one spends hours at a time using, so the slicker operation you can get from a JS-heavy system isn't really very valuable. Short version: a tool like the MM web interface should minimize the possible failure modes even if that means sacrificing some fluidity of use. -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Is Mailman 2.1 not plushack aware?
On 2 Jun 2013, at 11:50, Tanstaafl wrote: On 2013-06-01 1:40 PM, Bill Cole wrote: It is altogether always wrong for ANY mail software outside of a domain to parse the local part of an address in that domain except for a tiny handful of standard special local parts (e.g. "postmaster"). On it's own, I agree. The use of '+' as a tag delimiter is widespread but it is not in any sense a "standard" and comes nowhere near universality. There is no way for a Mailman instance to know which domains make "user+tag" and "user" equivalent and which do not, so canonicalizing as you suggest would result in breakage. Currently factually and technically correct, But... There is no reason that Mailman couldn't be enhanced with a configurable *option* that would allow the domain Admin to *tell* it which character(s) (there was recent talk on the postfix list of postfix being enhanced to allow multiple characters to be defined as this delimiter) were to be used as delimiters. There's no reason MM *couldn't* be "enhanced" in many ways that it never *should* be. It's reasonably well-structured open source Python after all... Beyond a few formally standardized cases, assuming equivalency between different address local parts in a foreign domain is wrong in principle and bad in practice. Postfix's recipient_delimiter has nothing to do with foreign domain addresses, it is only relevant to addresses in domains for which Postfix handles delivery. It is also worth noting one thing mentioned in that thread: it is trivial to replicate the functionality of having multiple delimiter characters with regular expression alias maps. The original poster's difficulty was that MM did not see "user@domain" as a valid confirmer of a subscription by "user+tag@domain" but it would be profoundly wrong for MM to do so. Making MM recognize multiple tag delimiters would multiply the wrongness. The solution for that original problem is not in MM, it is for people using tagged addresses to have the right mix of tools and presence of mind to send mail using a suitable address for each message, i.e. if you subscribe to a MM list as "user+tag", you need to confirm the subscription from "user+tag", NOT "user". There would be less of a problem with a subscriber-specific setting that would allow confirmed subscribers to tell MM that it should treat some pattern of tagged addresses as equivalent to their subscribed address. That would not address the OP's complaint, but it could help for people who are error-prone in how they send mail. I would love to see this ability in MM3... To solve what problem? I abandoned simple tagging years ago precisely because of would-be mail wizards who thought it could be useful to programmatically de-tag my addresses, allowing them to intentionally override up my personal and domain-level mail handling. In place of the transparent "plus hack" I now have slightly more complexity in server config that buys me and my users safer tagging while occasionally dropping a wannabe deliverability wizard into a blackholed moat of his own digging. The feature you want to see in MM3 would probably make it easier for a clueless MM admin to do that without bad intent or even thought. There's a certain bofhly appeal to that, but I try not to let that side hold sway. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Is Mailman 2.1 not plushack aware?
On 30 May 2013, at 14:30, Jay Ashworth wrote: I just subscribed to the virtualgl-users list at SF, and I subscribed with a plushacked email address, jra+vgl@ Got the confirmation email ok, of course, but when I tried to send something, it bounced "because I'm not subscribed to the list". I've never had that happen before, but it's possible that I've never tried to sub a plushack address to a Mailman list. Does Mailman in fact not understand plushacked addresses as subscription addresses, and that it should canonicalize them when a) checking for duplicate subscriptions and b) accepting messages for restricted lists? It is altogether always wrong for ANY mail software outside of a domain to parse the local part of an address in that domain except for a tiny handful of standard special local parts (e.g. "postmaster"). The use of '+' as a tag delimiter is widespread but it is not in any sense a "standard" and comes nowhere near universality. There is no way for a Mailman instance to know which domains make "user+tag" and "user" equivalent and which do not, so canonicalizing as you suggest would result in breakage. Beyond that risk of breakage, "canonicalizing" local parts which one does not own is wrong in principle: it violates the core assumption which makes Sendmail-style plus-tagging useful. The tagged address is supposed to be unique in the view of everyone except its owner and the owner's delivery agent, which can easily discern that an address is tagged (maybe with '+' but maybe not) and then handle the address and tag in whatever locally customized manner their whims dictate. Outside entities should never try to guess what those whims are at any particular time and more importantly should never translate an address from what it actually is to what their guesses about the owner's whims implies. Note: you might look at my address for this list and make any of a number of reasonable guesses about how its structure (which *IS* significant) relates to its delivery and handling. Most would be operationally wrong and none would be complete. I tag addresses in opaque ways precisely because of past rude & clueless attempts by others (mostly spammers) to break + tagging. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] From Header Changed
On 25 Feb 2013, at 8:26, Dennis Putnam wrote: I guess I'm not surprised either. Unfortunately with ISPs blocking outgoing SMTP there are few alternatives. That is generally a function of what sort of access you buy. The sad reality is that blocking port 25 helps limit the scale & cost of abuse desk and retail tech support operations, so ISPs block port 25 by default on their cheapest access accounts. Depending on your provider, you may be able to get port 25 unblocked just by asking for it or by paying a premium for a "business grade" account, but it can be difficult to run a mailing list from anywhere in the address space of a "consumer" ISP because of receiver-side filtering. I wonder if any of the pay SMTP servers would work any better. Intentional providers of paid SMTP smarthost service do exist in the market. Freemail operations exist to muster users for operations that sell their aggregated eyeballs or for "upselling" into revenue-producing services. Mail smarthost service, especially for anything of a "bulk" nature, is a costly and risky service to provide which doesn't provide much opportunity for a freemail operator to resell eyeballs or lead users to paid services, so it is natural that they are intentionally closing off the ability to use them as smarthosts for free. If you're willing & able to be a small-scale sysadmin, it may be worth the trouble to forget about buying SMTP smarthost service and instead get a small virtual private server with a reputable provider. Just as being on a consumer ISP network can mean that you share the aggregate reputation of everyone else on that network, routing mail through a shared smarthost (even one charging for service) throws your lot in with all of the customers of that service and buying a VPS on the cheap (e.g. Amazon EC2) means you end up at least partially sharing the reputation of everyone else using the same low-rent provider. It's unfortunate, but as the net has matured it has taken on some of the same features as the real world; the market value your home (real or presumed) is a source of prejudices made tangible in how likely strangers are to trust you. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] reject on max_message_size exceeded
On 7 Dec 2012, at 15:52, Carlos R. Pasqualini wrote: Hi i cannot find any way to reject emails (coming from valid senders) which exceeded the maximum allowed message size. mailman currently put them on hold, but i want to instantly reject it with an alert to the user. the only thing i found is: http://www.mail-archive.com/mailman-users@python.org/msg46813.html but i don't think that shall be good idea is there a simple/standard way of configuring this behavior? Not inside Mailman. A solution that does not require modifying Mailman code is to put the size restrictions in the MTA's configuration instead. Most MTA's support global message size limits so if you can live with one limit for all lists and all other addresses served by your MTA, you can just set that global limit as a fix. If you need more granularity, many mail filtering tools that act as adjuncts to an MTA (e.g. amavisd-new, mimedefang, etc.) can enforce recipient-specific message size limits before messages are accepted by the MTA. If you are already doing strong spam filtering there is a good chance that you have the tools you need in place, although it may take some work to implement a solution. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] split incoming mailserver from mailman
On 16 Aug 2012, at 8:33, Marcus Schopen wrote:
Hi,
I'm looking for a way to separate the incoming mailserver which
handles
the addresses from the mailman instance, which sends mails out. I'm
running sendmail as MTA. The wrapper in /etc/aliases
("|/var/lib/mailman/mail/mailman ...) seems to have no option to
transport the incoming email e.g. by http requests to a remote mailman
server. Any ideas?
As is documented, Mailman needs to run on a machine with Python and a
MTA. The only mechanism for submitting mail to a Mailman list is by
piping a message to the mailman executable and that is done most easily
by having the MTA deliver incoming Mailman messages via a piped alias.
To use another transport, you'd probably have to write the transport
code yourself.
Having the unfortunate architectural problem of list addresses in a
domain that has other types of mail which you want to segregate from
list traffic can be partly mitigated by having the inbound MTA(s) for
the domain use special-case routing for the list-related addresses. The
main server can pass mail for those addresses to the Mailman server
which "delivers" mail for those addresses locally (i.e. through aliases
that pipe messages to mailman.) Mailman then can send outbound mail via
its local submission subsystem and whatefver outbound routing that uses
(i.e. the local MTA or a relaying MTA.) For Sendmail, that sort of
arbitrary address routing is probably best done using the mailertable
feature, with complementary tables on the main MTA server and the
Mailman server directing each others' addresses appropriately. As with
anything involving Sendmail there are also other ways to implement that
which might be convenient if you already are using them (e.g. the
"mailhub" model, User DB, or handmade custom .cf code) but they would be
harder fits than the mailertable.
--
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] SPF MAIL FROM check failed: [MAIL_FROM]
On 9 May 2012, at 20:32, David wrote: On Wed, May 9, 2012 at 4:01 PM, David wrote: Re: Giving away the secrets of 99.3% email delivery 1. Constantly monitor spam blacklists. We have a set of Nagios alerts that regularly check if we’re listed on any delivery blacklists, and whenever they go off we take whatever corrective action we need to get back off the blacklist. 2. Have valid SPF records. Don’t impersonate your users. When running a web app like Basecamp, which sends email that are generated by another user, it can be tempting to send the email from that user (e.g., so that a comment I wrote on Basecamp would appear to come from noah at 37signals dot com), which might make people feel more comfortable. Unfortunately, this is a surefire way to end up on spam lists, since you’ll likely be sending from an IP address that does not have the valid SPF records. And chances are, if the user’s domain does have an SPF record, it doesn’t include your application’s IP. 3. Sign the mail! DKIM and Domain Keys. Yahoo and Gmail both score signed email higher. 4. Dedicated and conditioned email sending IPs. 5. Configure reverse dns entries. Most of the “big boys” won’t accept mail from your servers if your reverse dns entries don’t match. You might need your IP provider to help with setting up these records. 6. Enroll in feedback loops. We haven’t automated our parsing of feedback, but a daily / weekly review of feedback loop emails helps us know when there’s an unhappy user, or other problem. Too many complaints and you’ve got trouble. Something about how you are composing mail is resulting in an ugly mess on the receiving side, with your quoting completely broken. See above as an example. Perhaps sending as HTML and having it whacked by Mailman... I started by setting up an SPF record (#2 on the list above). However, shortly after setting it up, we got a bounce with this reason: SPF MAIL FROM check failed: [MAIL_FROM] I searched a bit and came across things like this: http://comments.gmane.org/gmane.org.user-groups.linux.new-zealand.general/34245 But nothing I found answered my questions. Looking at the headers of the bounced message, I note: Received-SPF: pass (domain of lists.example.com designates 10.10.10.99 as permitted sender) X-Originating-IP: [10.10.10.99] That would seem to indicate things are OK, but maybe X-Originating-IP isn't the line I need to be looking at... I'm not sure what [MAIL_FROM] (in the SPF check failed line) matches in the email header. This is probably running off the topical edge of the Mailman-Users list, but I'll be brief. Before publishing an SPF record, you should understand what SPF is and how it works. If you don't understand it, don't try to use it. SPF is a weak but sometimes useful mechanism that allows a SMTP server to check whether a given SMTP envelope sender address (a.k.a. "Return-Path" or "MAIL_FROM" or "bounce address") should be trusted as valid when given by the particular IP address of an SMTP client, using DNS records. In most cases it is only applied to the domain part of an address. There's not much else to say about your specific problem, since you seem to have obfuscated everything of significance about the specific message with a problem. For example, and most importantly, "lists.example.com" is bogus. The SPF coherency to check is between the outbound IP address of whatever machine (at Yahoo??? ugh.) generated that bounce and the domain you've obfuscated as lists.example.com. Your SPF record(s) need to the reality of where mail systems to whom you are not known will be receiving your mail from, not the original source of your mail. So if you have made the inexplicable decision to route your mail out via Yahoo, you need to consult with Yahoo about how to set up your SPF record(s). Also, I note: X-YahooFilteredBulk: 10.10.10.99 <-- what does "X-YahooFilteredBulk" mean? Ask Yahoo. Any email header that starts with "X-" is non-standard and could mean anything or nothing. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Is Character Permitted
Mailman Admin wrote, On 11/9/11 10:25 AM: On 2011-11-09 09:55, David Andrews wrote: Is the "&" character allowed in a list name, such as in: "art&artists?" No, as it must be a valid email address. In email addresses are only the following characters allowed a to z A to Z 0 to 9 . - _ That is quite significantly incorrect. Refer to RFC5322 section 3.2.3 (http://tools.ietf.org/html/rfc5322#page-13) which defines the syntax of the "atom" and its sub-unit "atext" which are the building blocks for the local part of an email address. The allowed characters (the "atext" set) in the "atom" components of an address local-part (delimited by '.') which do not use the unusual quoted string syntax are all printable ASCII except for whitespace and these 13 characters: <>[]()@;:.\," That character set has been unchanged in the Internet Message Format RFC's going back to RFC822. Obviously, the '.' is barred from the "atom" components of a local-part because it is used between them. See RFC5322 for the full ABNF spec. RFC5321 (the SMTP specification) refers to the RFC5322 spec. Whether *Mailman* handles '&' correctly in a list name is a different question. There are many cases of mail software being more restrictive than the specification about addresses, and I have not dug into the Mailman docs to nail down what it will accept as a list name. Also, I would be very uneasy about using any character (like '&') which is commonly used with special meaning in languages that are popular on Unix systems. I know that Python is generally pretty good about strings containing metacharacters, but when you send mail you never know what else other than your own tools will have to handle it. In a world full of perl, shell, m4, and sendmail.cfese I would be very dubious about using addresses containing ampersands, backticks, apostrophes, and other theoretically acceptable characters. They are formally legal but if you are picking an address to use, you should avoid making making such challenges to code quality. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] exclude lists question
Mark Prewitt wrote, On 1/6/11 1:54 PM: Good Day, I have two lists that have essentially the same members except for one person. Unfortunately, they are client facing lists and we have different clients using them so we cannot combine them or eliminate one which would make this so much easier. List a has 5 people on it List b has 6 people on it When we send an email to lista& listb many of the people get 2 emails, so we put listb in the lista exclude list and lista in the listb exclude list. What happened then was surprising, no one got any emails, even the non-duped people (as far as I have been able to tell anyway). This is as documented in the web interface's "details" page for regular_exclude_lists: Do not specify this list address mutually in the exclude list configuration page of the other list, or members of both lists won't get any message. Anyone have an idea why this would happen and how to resolve it? This has been raised here before and answered, e.g. the second half of my long message at http://www.mail-archive.com/mailman-users@python.org/msg57524.html The setup I described there works, i.e. my regular_exclude_lists settings for 4 siblings is like this: list4: list1, list2, list3 list3: list1, list2 list2: list1 list1: (empty) This assures that no list excludes a sibling list that excludes it in return. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
