Mailman 3 September 2015 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett Nov. 7, 2022

Nov. 7, 2022

Hi. There's a fairly simple problem here that needs to be addressed. And it's mostly a documentation/install problem. I'm hoping we can get this resolved before the next release. PROBLEM: Mailman comes out of the box ready to backscatter spam people. Yes, it's easy enough to fix. But because it comes stock this way, and is documented to install this way, most people install it to do this. Those of us who work in abuse departments are tired of hearing "well that's how Mailman works". We also object to having to teach people how to fix their mailman installations because it's not documented in the current manual. This is *exactly* like Sendmail 14 years ago. We didn't accept it then, and Sendmail fixed the problem. RESOLUTION: Mailman default installation should not backscatter in a default configuration. 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by default. Nearly everyone uses web based signup. 2. Discard or hold messages from non-subscribers by default. I would think that it would be perfectly reasonable to have documentation on how to enable the 1980s-style -request / -subscribe etc aliases. However this documentation should have a note that this is against the AUP of nearly every network provider, and enabling it will likely cause them to get listed in various blacklists as a backscatter source. FYI: I know that this goes against the instincts of many old-time mailing list advocates here. But after dealing with a 10k/hour backscatter DoS my tolerance for this problem is understandably limited. Yes, it was a sweet day back in the 1980s. I was running a mailing list server and several UUCP gateways at the time, so I remember them well. But those days are past, and we need to deal with the reality of today. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

21 168

Let's try to package mailman3 in Debian!
by Pierre-Elliott Bécue Feb. 22, 2016

Feb. 22, 2016

Hey, As a Debian fanboy and also a mailman addict, I'd like to try packaging it in Debian. As I'm not a DD and as I'm not in a hurry, I'd like to take some time to think about what would be relevant. For that, I'd like to have some help. And I was suggested to come here and ask. I decided to use https://gitlab.com/groups/mailman as a basis for my work. First of all, to create the source package, I've to think about what to put in it. It seems that if I want to have a good source package, I need 5 repos : - Mailman - HyperKitty - Postorius - HyperKitty - MailMan Plugin - MailmanClient My first question is "Am I right?". And the second one is whould I consider looking into mailman-suite-doc and also have it in the source package? On another way, I also see that there is a standalone postorius repo and also some django project files for HyperKitty in another one. I have the impression it is more designed for people to work on as standalone - forkable projects for other features, and so I wouldn't need them in a Debian package. Am I also right? Thanks for your answer, I hope I'll be able to make this package look as you'd like. :) Cheers, -- PEB

5 13

Re: [Mailman-Developers] Mailman 3.0 on centos 7
by Fabian Santiago Sept. 29, 2015

Sept. 29, 2015

That's awesome. I'll check this out ASAP. Thank you for your help. Sincerely, Fabian Santiago Sent from my iPhone > On Sep 29, 2015, at 10:37 AM, Aurelien Bompard <aurelien(a)bompard.org> wrote: > > Hey Fabian, > >> Does anyone know where I can find more info on deploying mailman 3 on centos 7 aside from the standard docs site? > > I'm currently packaging Mailman3 and HyperKitty + Postorius for Red > Hat / CentOS 7. My packages are here: > https://repos.fedorapeople.org/repos/abompard/hyperkitty/el-7/x86_64/ > and the repo file is here: > https://repos.fedorapeople.org/repos/abompard/hyperkitty/hyperkitty-el.repo > The repo contains all the dependencies too. > > However, I'm updating the packages as I go, so they may be unstable, > contain unreleased patches and branches, etc. The SRPMs are there so > if you want to start with that and write your own, go ahead. > I hope it saves you some time. > > > Aurélien

1 0

Mailman 3.0 on centos 7
by Fabian Santiago Sept. 29, 2015

Sept. 29, 2015

Does anyone know where I can find more info on deploying mailman 3 on centos 7 aside from the standard docs site? I am having some difficulty and am unfamiliar with the python virtual env stuff so I'm interested in any help anyone can provide. Thanks all. Sincerely, Fabian Santiago Sent from my iPhone

2 1

DMARC and Mailman 3
by Dean Suhr Sept. 29, 2015

Sept. 29, 2015

Can someone clarify the optimization of Mailman 3 for MARC? I’ve installed and the options are slightly different than MM 2.1.x and the documentation in the Wiki here: http://wiki.list.org/DEV/DMARC <http://wiki.list.org/DEV/DMARC> which is fine, but I can’t find any post-release documentation. The developer archives are mostly discussions from 2013. Here’s the current option page and my take on them: Filter content: [?Should Mailman filter the content of list traffic according to the settings below?] … this seems to be a master switch for everything below. Collapse alternatives: [?Should Mailman collapse multipart/alternative to its first part content?] … not DMARC Convert html to plaintext:[?Should Mailman convert text/html parts to plain text? This conversion happens after MIME attachments have been stripped.] … not DMARC Anonymous list: [?Hide the sender of a message, replacing it with the list address (Removes From, Sender and Reply-To fields)] … affects DMARC but not good for discussion/Reply to list style lists Include RFC2369 headers: … not DMARC Include the list post header: … not DMARC Explicit reply-to address: … not sure how/if this affects DMARC (which is a FROM thing). Also not sure who this interest with REPLY GOES TO LIST, below. First strip reply to: … not explicitly DMARC … and how it interacts with EXPLICIT and REPLY GOES TO LIST options - seems like it must be done of either other option is enabled Reply goes to list: [?Where are replies to list messages directed? No Munging is strongly recommended for most mailing lists. This option controls what Mailman does to the Reply-To: header in messages flowing through this mailing list. When set to No Munging, no Reply-To: header is added by Mailman, although if one is present in the original message, it is not stripped. Setting this value to either Reply to List or Explicit Reply causes Mailman to insert a specific Reply-To: header in all messages, overriding the header in the original message if necessary (Explicit Reply inserts the value of reply_to_address). There are many reasons not to introduce or override the Reply-To: header. One is that some posters depend on their own Reply-To: settings to convey their valid return address. Another is that modifying Reply-To: makes it much more difficult to send private replies. See `Reply-To' Munging Considered Harmful for a general discussion of this issue. See Reply-To Munging Considered Useful for a dissenting opinion. Some mailing lists have restricted posting privileges, with a parallel list devoted to discussions. Examples are `patches' or `checkin' lists, where software changes are posted by a revision control system, but discussion about the changes occurs on a developers mailing list. To support these types of mailing lists, select Explicit Reply and set the Reply-To: address option to point to the parallel list.] * Does selection REPLY-TO put in a reply header as well as re-write the FROM header? * I want a REPLY to LIST style list where replies always go to the list. Ideally, I'd like to see the sender’s name (And even email) in text portion of the FROM address even if the list address replaces the FROM address - which I think would solve the FROM/DMARC problem. Pipeline: [?Type of pipeline you want to use for this mailing list] … can’t find any documentation on this Thanks in advance, Dean

2 1

Mailman 3.0 + Qmail support
by Fabian Santiago Sept. 15, 2015

Sept. 15, 2015

Hello, Just re-posting this on the appropriate list this time; Any plans to support Qmail along with Mailman 3.0 and above? -- Fabe

2 2

Mailman 3 packages for Archlinux
by Simon Hanna Sept. 13, 2015

Sept. 13, 2015

Hi, I just finished packaging Mailman 3 for Archlinux. I divided it into packages as follows: mailman-core: the core mailman installation mailman-django-git: a skeleton django project for serving hyperkitty and postorius python2-django-postorius: the postorius module python2-django-hyperkitty: the hyperkitty module python-mailman-hyperkitty-plugin: hyperkitty plugin for archival python-mailmanclient: python bindings for rest api python2-mailmanclient: python bindings for rest api python2-django-postorius-git: the postorius module (git-version) python2-django-hyperkitty-git: the hyperkitty module (git-version) mailman-suite-git: A dummy package installing everyhing that can be installed For the dependencies I choose to go with that: mailman-core: optionally depends on python-mailman-hyperkitty-plugin optionally depends on python-mailmanclient optionally depends on python2-mailmanclient mailman-django-git: optionally depends on python2-django-postorius-git optionally depends on python2-django-hyperkitty-git optionally depends on python2-whoosh python2-django-hyperkitty: depends on python2-mailmanclient python2-django-postorius: depends on python2-mailmanclient I will push non-git versions of mailman-django-git and mailman-suite-git. However, currently they wont work, as hyperkitty's change from {{ STATIC_URL }} to {% static %} is currently not yet released (just in master branch). My mailman-django skeleton however requires {% static %} Currently one dependency of hyperkitty isn't met yet, because python2-django-compressor should be depending on python2-django-appconf. However it's maintainer didn't add it. I am trying to contact him and should resolve this within the next week. The packages can be found in the AUR under this link: https://aur.archlinux.org/packages/?SeB=m&K=thelinuxguy&O=0&PP=50 the whole dependency tree is as follows: (it's probably not a complete list, but these packages should be present for Mailman3 to work) mailman-suite: mailman-core postfix python-alembic python-falcon python-flufl-bounce python-flufl-i18n python-flufl-lock python-httplib2 python-lazr-config python-lazr-delegates python-lazr-smtptest python-mock python-nose2 python-passlib python-sqlalchemy python-zope-component python-zope-configuration python-zope-i18nmessageid python-zope-schema python-zope-event python-zope-interface python-mailman-hyperkitty-plugin mailman-django python2-django-hyperkitty python2-django lessc (nodejs-less) python2-dateutil python2-django-browserid python2-django-extensions python2-django-compressor python2-lxml python2-django-appconf python2-django-crispy-forms python2-django-gravatar python2-django-haystack python2-django-paintstore python2-django-rest-framework python2-enum34 python2-networkx python2-pytz python2-robot-detection python2-social-auth python2-jwt python2-oauthlib python2-openid python2-requests python2-requests-oauthlib python2-six python2-mailmanclient python2-django-postorius python2-django python2-django-browser-id python2-httplib2 python2-mailmanclient python2-whoosh python-setuptools, python2-setuptools and git needed for building the packages

1 0

Re: [Mailman-Developers] Migration of header_filter_rules
by Barry Warsaw Sept. 11, 2015

Sept. 11, 2015

On Sep 11, 2015, at 04:25 PM, Aurelien Bompard wrote: >If you want to look at it : >https://gitlab.com/abompard/mailman/commits/import-header-matches I took a brief look, and I think you're heading in the right direction. I'll do a more details review once the mp is up[*]. >In the code and in the tests, I'm importing the new model object, >HeaderMatch. Is it OK? Should I go through the corresponding interface >instead? It looks like models are almost never imported from throughout the >code (except in the model module), and I don't know if that's a best practice >that should be followed here. If it is and you have details on the reasoning, >I'm interested :-) You're right that model classes should never be imported outside mailman/model although there are a few violations of this rule. It's less hard-and-fast for tests since sometimes that's just the most convenient way to handle it. In cases like this though, the typical pattern is to create a "set" class in the model, and use it to create, delete, and lookup model objects in the set. For list-centric collections, you then also create an ZCA adapter which returns an object in the context of the mailing list. It's always easier to understand examples, so here's a classic. Mailing lists have an associated set of acceptable aliases which are kept in the acceptableasliases table. Individual alias entries are defined by the IAcceptableAlias interface and implemented by the AcceptableAlias class. There's also an IAcceptableAliasSet and AcceptableAliasSet pair (the latter which does *not* derive from Model), and you'll find .add(), .clear(), and .remove() methods, and a convenience .aliases attribute. So, you never add AcceptableAlias objects directly, you always do it through the IAcceptableAliasSet interface. How do you get an instance of that without importing from the model subpackage? You *adapt* an existing mailing list object to that interface: from mailman.interfaces.mailinglist import IAcceptableAliasSet ... alias_set = IAcceptableAliasSet(my_mlist) The thread that ties it all together is this claus in src/mailman/config/configure.zcml (the configuration file for the Zope Component Architecture -- ZCA): <adapter for="mailman.interfaces.mailinglist.IMailingList" provides="mailman.interfaces.mailinglist.IAcceptableAliasSet" factory="mailman.model.mailinglist.AcceptableAliasSet" /> Thus when you call the interface, passing in the IMailingList instance, the ZCA looks up a factory providing that interface, and calls the object, passing in the argument. You can see that AcceptableAliasSet takes a single argument, the mailing list object which provides the context for that object's operations. I think header checks will probably work almost exactly the same way. Cheers, -Barry [*] Side note: NFL season starts here in the USA this weekend, and there's no better way to salvage a Sunday afternoon normally wasted watching your crappy ass home team disappoint for another year than doing some fun Mailman hacking as you scream at the TV. Just resist the urge to throw your laptop through the TV!

2 1

Re: [Mailman-Developers] Migration of header_filter_rules
by Stephen J. Turnbull Sept. 11, 2015

Sept. 11, 2015

Aurelien Bompard writes: > Hmm, do you think so? I would have thought that list settings > should take precedence, since they are the most precise. A list > could decide to not filter the spam and deal with it in their own > manner (holding it instead of discarding it). That makes sense when list-owner == site-owner. However, a list which is misconfigured or just doesn't care can hurt the reputation of the whole site. Also, there are the emergency cases that Barry mentioned, where you want to flip one switch and turn the lights out for spam. So maybe there should be "site defaults" which list owners can override, and "site configurations" which are final. Steve

2 1

Re: [Mailman-Developers] Migration of header_filter_rules
by Barry Warsaw Sept. 10, 2015

Sept. 10, 2015

On Sep 10, 2015, at 11:33 AM, Aurelien Bompard wrote: >> It's probably going to require a separate table foreign >> keyed to the mailing list which contain a list of regexps and their actions, > >Yeah, it's currently a python list pickled into the header_matches >field of a mailinglist, we can do better :-) Yes, let's eat the pickles! :) >> I'm not sure that the current semantics of header-match need to be >> preserved. If a list admin wanted one of their regexps to trigger the >> site-defined action, they could just choose it themselves. I don't think >> we need to keep it for backward compatibility reasons, but we do need to >> migrate any existing header_checks to the new feature (i.e. for people >> upgrading from MM 3.0 to 3.1, as this will obviously be a 3.1-only >> feature). I suggest using the config.antispam.jump_chain value as the >> default value for the new header_checks regexp value. > >We could decide that the chain to be jumped to is nullable, in which >case the action would be defer, which would end up in the site-defined >chain like in the current model. Then the existing chain could just >use that and get the same behavior. That might indeed be a better way to go, so if the site-defined action is changed, the change will get picked up. The downside of course is that a restart is needed. It might be better to move the site checks out of the config file and into the database. It could work the way bans work, where if there is a list-id context, it's a list-specific ban, and if there is no associated list-id, it's a site-wide ban. Don't feel you have to do this extra step, but it might be easy. >> You'll have to disentangle the site-wide header checks with the >> list-specific header checks, but maybe that can be done in the .get_links() >> method. Site-wide settings should take precedence. > >Hmm, do you think so? I would have thought that list settings should >take precedence, since they are the most precise. A list could decide >to not filter the spam and deal with it in their own manner (holding >it instead of discarding it). My thinking was that site owners have greater permission and responsibility, so their preference should win. It might be interesting to have a way for a site admin to say "here's the default, but let list admins override" vs. "here's site policy, you cannot override". This seems like a not-uncommon pattern, especially if you add a domain-owner's preferences here. There's a hierarchy that's often repeated. But generalizing that, or even supporting it in this case can very definitely happen in a future feature. Cheers, -Barry

1 0