[Mailman-Users] Scrubber: filename too long

[tlhackque via Mailman-Users]

>From /usr/lib/mailman/cron/senddigests, I'm seeing this - which is the
result of an annoying webbug URL in some (actually important) inbound
messages.

I guess one approach would be for the filename name to be simply the
sha-xxx of the generated name...not being a Python person, what's the
best way to solve this?


Traceback (most recent call last):
  File "/usr/lib/mailman/cron/senddigests", line 94, in ?
main()
  File "/usr/lib/mailman/cron/senddigests", line 86, in main
mlist.send_digest_now()
  File "/usr/lib/mailman/Mailman/Digester.py", line 60, in send_digest_now
ToDigest.send_digests(self, mboxfp)
  File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 142, in 
send_digests
send_i18n_digests(mlist, mboxfp)
  File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 324, in 
send_i18n_digests
msg = scrubber(mlist, msg)
  File "/usr/lib/mailman/Mailman/Handlers/Scrubber.py", line 301, in process
url = save_attachment(mlist, part, dir)
  File "/usr/lib/mailman/Mailman/Handlers/Scrubber.py", line 506, in 
save_attachment
fp = open(path, 'w')
IOError: [Errno 36] File name too long: 
'/var/lib/mailman/archives/private/sb-notices/attachments/20200617/7bfd746c/openupnuTyAIB5RnlGqcUYpxASzOCjK0U2XEEfdN09lb80k8EAccOT3iskue1a45bqJenPWT4XeDAj9c-2FnJ-2F1UfxwtikwjXfVn4FKSvPvMQ4-2F-2BnoeZraMSMf1dLwio-2FiUT1wYNZx4eF1A5j8DF1-2FMAhxu72-2BX1pzdJx1CWDywpoyPVWKwluqE4AyFhrreaxc8kYpHZaUFUlP3MPFmNEDQ5Tr-2Bg-2BJRAhSYLdif3kj8rKn-2FDEhbw-3D.gif'

--
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] Automatic subscription based on e-mail subject

[tlhackque via Mailman-Users]

On 31-Jan-19 05:11, R. Diez wrote:
> Hi all:
>
> I have the following recurring problem with mailing lists all over the
> Internet: people do reply to my posts, by they do not address or copy
> me in their replies. They send their e-mails only to the mailing list.
> Or they reply to the previous reply, and forget to copy the original
> poster.
>
> So I do not get a copy of the relevant messages straight away. If need
> to manually fish their answers from the web interface. If there is
> one. And then composing e-mails is cumbersome. And the subject
> threading no longer works properly.
>
> This problem has annoyed me (and other people on the Internet) for a
> long time.
>
> I cannot subscribe to every mailing list I need to occasionally use.
> It's far too much. This e-mail is the perfect example of such a
> come-ask-and-go-again scenario.
>
> If I need to subscribe in order to post a question, I turn off mail
> delivery straight away.
>
> Getting a digest with all e-mails does not help either. Replying to a
> single e-mail in this mode is cumbersome too. Besides, I do not want
> to manually skip other messages which do not interest me.
>
> Other forum software has a nice feature for this scenario: If I post
> to a subject, I am automatically subscribed to that subject. I then
> get an e-mail for any new posts with the same subject.
>
> The "topic" feature in Mailman is different. Very few people use it. I
> need something based on the e-mail subject.
>
> Is there any way to achieve that with Mailman?
>
> Thanks in advance,
>   rdiez
>
>
While I sympathize, I should also point out that this behavior goes
against the underlying philosophy of many mailing lists.

In that context, it is viewed as "selfish" to only ask for help while
never providing any.  If you don't read the list, you can't offer help
to others.  You don't have to be an 'expert' to be able to answer
questions, or to help an 'expert' to understand a novice's point of
view.  Communities are built from cooperation.

It should be up to a list owner to decide whether or not to enable a
feature that facilitates "take but don't give" behavior.  The list norms
should decide if "ask and run" or "ignore everyone else" is considered
anti-social/exploitive or acceptable use. 

In my experience, people paid to support a product might be happy with
the feature enabled, while a volunteer community might oppose it. 

Of course, today you can subscribe to the list and put a client-side
filter in your MUA that discards any post that doesn't reference your
post.  (By subject or "References" header.)  That doesn't require any
new support in Mailman.


--
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] Mod_Security

[tlhackque via Mailman-Users]

On 08/01/2018 09:43 AM, Bernie Cosell wrote:

> And I tried my program on the Bluehost version and I was greeted with 
>
> Not Acceptable!Not 
> Acceptable!An appropriate representation of the requested 
> resource could not be found on this server. This error was generated by 
> Mod_Security.<

mod_security is an Apache webserver module that has a complex ruleset
used to examine every request and response.  It attempts to detect and
prevent malicious activity.   Doc on https://www.modsecurity.org.

It is not uncommon for form submissions to run afoul of mod_security
rules.  Typically, there are cases where data is encoded in ways that
appear to be hiding something - e.g. %-encoding urls or POST data
where it's not necessary, excessively long URLs or large POSTs - and
so on.  There's a pretty large list.  Most are regex s applied at
various stages of request processing; some are based on things like
request size.  Some are rules that assume a pretty dumb web service;
where you know that Mailman can cope with constructs/sizes/encodings,
you're expected to disable those rules on the URLs that it serves.

There will be logs on the server that specify exactly what rule was
tripped, it's id, and the suspect input.

Then there are three courses of action possible:
 o The rule can be disabled by ID in the webserver config, for the specific
   mailman POST URL (or globally, but that's not smart).  It's also possible
   to completely disable mod_security for a URL or vhost - but that's also
   not advisable.
 o Mailman can be changed to not require input that trips the rule.
 o Your client can be changed not to generate input that trips the rule.

You will need help from someone with admin privs to at least share the logs,
if not make adjustments to the mod_security configuration.  Like any
protective filter, it takes some thought and analysis to make the right
changes.  That is the change that allows what you want, but doesn't open
an unintended attack surface.

In my experience, these issues are never caused by just one rule - if an
application trips one, waiving or fixing it will only get you to the next
one.  It can take a while to get to a workable ruleset.  It is generally
worth the trouble, as mod_security is effective at protecting against
quite a few exploits.  It does take a while to learn how it works and how
to teach it how to stay out of your way.

There are two things likely to be changed on the server end:
The webserver config file that will include directives to disable
specific rules on particular URLs.  And possibly a set of customized
rule overrides for Mailman.  (These can go in separate files that
are dropped in the rules directory.)

Once that's done, sharing the result with the MM community would save
others a lot of repeat effort.

Good hunting.

--
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] analytics tool for mailman?

[tlhackque via Mailman-Users]

On 24-May-18 17:06, Julian H. Stacey wrote:
> who just now wants extra analytics from Mailman, real bad timing !
> GDPR law hits Europe in 1 hour if CET or 2 maybe in BST, & 
> Many people in major through tiny companies & orgs (way beyond
> a few of us Mailman admins) are freaking about that, & that law
> was [presumably] triggered by misuse of analytics.
>
I hesitate to get into the GPDR discussion, as I have no qualifications
(and little interest) in that area.

However, GitLab's recent missives on the subject reference their new
terms of service, which

include the following snippets that may be of interest:

As part of my voluntary contribution to any GitLab code base, I
acknowledge and agree that my name and email address will become
embedded and part of the repository, which may be publicly available. I
understand the removal of this information would be impermissibly
destructive to the project and the interests of all those who
contribute, utilize, and benefit from it. Therefore, in consideration of
my participation in any project, I hereby waive any right to request any
erasure, removal, or rectification of this information under any
applicable privacy or other law and acknowledge and understand that
providing this information is a requirement under the agreement to
contribute to the GitLab project.

Please note that due to the open source nature of our products,
services, and community, we may retain limited personally-identifiable
information indefinitely. For example, if you provide your information
in connection with a blog post or comment, we may display that
information even if you have deleted your account as we do not
automatically delete community posts. Also, as described in our Terms of
Use, if you contribute to a GitLab project and provide your personal
information in connection with that contribution, that information
(including your name) will be embedded and publicly displayed with your
contribution and we will not be able to delete or erase it because doing
so would break the project code.

See https://about.gitlab.com/terms/ and https://about.gitlab.com/privacy/

I have no opinion on the wisdom or bases of GitLab's position.  As
mailing lists share some characteristics with their services, those who
have to deal with GPDR may wish to consider it in developing their own.


--
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] Brute force attacks on mailman web ui

[tlhackque via Mailman-Users]

On 19-Apr-18 23:33, Stephen J. Turnbull wrote:
> tlhackque via Mailman-Users writes:
>
>  > I'm not sure what you are looking for.
>
> I'm looking for anything that will help block swaths of Chinese
> spammers and possibly attacks, while allowing me to do a better job of
> serving students vacationing at home in China than treating them the
> way the Chinese government does.  A unicorn, or failing that, a pony.
So you know exactly who your users are, and can pre-register them while
they are
not in China.

Geographic IP address is the wrong hammer for this nail.
Block the country, open pinholes for the users.

> No, I want to identify good actors and block the rest.  The problem
> I've had in the past is that I can't depend on static IPs because I'm
> dealing with people using telephones, mostly.
GeoIP will never get you down to the level of granularity and accuracy
that you want.
Even if it did, people with phones move - apartment, coffee shop, etc. 
>  > One option is to provide a website for registering your users, then
>  > allow them access via some convenient token.
>
> I'm not sure what you're suggesting.  That's what is being attacked
> here.
If you're seeing webserver attacks, you'll also see mailserver AUTH
attacks. I assumed both.

It's easier to protect a website than a mailserver.  Plus, registration
is a one-time activity.
And in your scenario, you can block all of China, since you can register
your students while
they are at your school (which presumably is not in China).

So use the registration website to issue an X.509 certificate, register
a hardware token, issue fwknop
key - whatever you choose as your token (credential).  Then use that
token to protect routine access to the mailman web ui AND mail servers.

Even if you allow registration from China, you can make the registration
website available
at limited times.  E.g. odd days of the month from 1341 to 1417.  This
drastically reduces
your attack surface.  You tell your users the algorithm for when they
can use it to register,
or more likely, invalidate a lost key & get a new one, etc.  Change it
every semester.


>  > Or provide a VPN (with just your web or email server as an
>  > endpoint).
>
> I believe the Chinese have outlawed VPNs, I assume they allow TLS
> still, though, given the size of ecommerce there.
I believe you are correct.  They may use spoofing on TLS, so unless you
use some form of pinning, assume MITM. 
>  > Or use X.509 client authentication  - note that you can use this
>  > with your mailserver.
>
> That's an interesting idea, but again my users will be mostly using
> phones, so I don't think this will work with mail very well, and I'm
> not sure how to set that up on a phone.
Mobile MUAs not my area of expertise, but it ought to be possible.  Both
sendmail and postfix allow it to be configured.
Even if you don't have a native MUA, you can provide a web-based e-mail
account on your server for your users - e.g. squirrelmail, roundcube,
etc.  Put client auth on that (easy); allow that server access to your
e-mail server, perhaps just on localhost.  Mobile web browsers certainly
support x.509 client auth.  If you go this route, you only need to open
a TLS port; you don't need IMAP/POP3/SMTP/Submission.  You will still
get kiddie script attempts, but TLS will block them for lack of a
(valid) client certificate.  These are less common, and combined with
fail2ban should work reasonably well.

From your revised description, fwknop seems to be a good choice.  It's
cheap, transparent, easy to setup, and should traverse the great
firewall.  (No direct experience, but the technology is hard to block,
especially if you overlay it on a web or mail server.)  You can use it
to protect both. 

Issue their keys before they go home, and you're done.  Optionally,
provide some form of recovery/reissue for the "I lost my phone" case. 
Or just say "don't lose your phone; if you do, you're out of luck for
the rest of your trip."

Providing an e-mail service as outlined above is more expensive, but
provides an additional service for your users.

In any case, I think we've probably exhausted the patience of
mailman-users since we're off into the general problem of keeping our
servers alive in the jungle...

Good luck.

--
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] Brute force attacks on mailman web ui

[tlhackque via Mailman-Users]

On 19-Apr-18 02:46, Stephen J. Turnbull wrote:
> So here's my problem.  A lot of my constituency resides in CN,
> occasionally including people at frequently problematic domains like
> 163.com.  Do you know any resources (or keywords to start googling
> even!) at subnational levels?  KR and CN breakdowns would be most
> useful to me; breakdowns for RU and former USSR would be appreciated
> by many of my colleagues.
>
I'm not sure what you are looking for.

Blocking by geography is a very crude tool - it turns out to be useful
in that many hosts serve limited geographies, and it's pretty easy to
identify countries that generate a lot of "bad" traffic.  E.g. RU & CN
are widely believed to support intrusions by (pseudo/)government actors,
and rarely prosecute. 

As you discovered, below that level, you need to use other tools.

There are a number of geolocating services that attempt to turn IP
addresses into specific locations; for example maxmind offers a series
of databases of increasing precision for increasing prices (starting
with free).

You can use these databases with your webserver (e.g. apache mod_geoip)
and name server (BIND for sure).  There is also a GeoIP module for
iptables.  (I use (and maintain) BlockCountries because it is more
flexible and easier to use. YMMV).

But the problem is that unless you know exactly where your users (and
potential users) are located, this won't help.  Do you have a list of
cities?  Streets?  I don't think that the criminal element has easily
identifiable geographies.

What you probably want is to identify the specific bad actors; for that
the spamhaus and other "block lists" ("RBL") are helpful.  Most of these
are distributed via DNS - which means that they aren't practical for
firewalls.  You can configure your email server (e.g. sendmail/postfix)
to use them.  But this happens inside your firewall.  These lists are
fairly well curated, but certainly aren't perfect.

As previously noted, fail2ban is one reactive means of dealing with
these - it reads log files and dynamically blocks IP addresses that
generate errors.  It can be resource intensive, especially if you want a
reasonably fast reaction time.  And specifying bad behavior is somewhat
of an art.

One option is to provide a website for registering your users, then
allow them access via some convenient token.    A Captcha will help to
reduce fraudulent registrations.  E.g., if they have a static IP
address, register that.  Or provide a VPN (with just your web or email
server as an endpoint).  Or use X.509 client authentication  - note that
you can use this with your mailserver.  For this purpose, you want your
own CA for X.509.  You can revoke abused tokens.  If your community is
small (or willing to pay), you can look at hardware tokens, such a yubikey.

That will work if you have a reasonably sized community - and people
really want to use your service.  However, if you're trying to attract
people who don't know if they are interested, the cost of connecting
with you would probably turn many away.

It's a balancing act, and your business (community, etc) needs will
determine what is best for you.

Note that I'm not exclusively endorsing any of the products/services
mentioned - there are alternatives, and you need to evaluate what each
offers against your needs.

Unfortunately, there's no universal answer.

Good luck.

--
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] GSOC idea: mail server/DNS server/mailing list healthcheck

[tlhackque via Mailman-Users]

On 17-Apr-18 10:28, Rich Kulawiec wrote:
> The idea for this comes from some of the web sites that perform this;
> unfortunately most of them are "upgrading" from simple, fast, easy
> checks to bloated ones that use a ton of Javascript, can't be scripted,
> and are increasingly behind signups/paywalls/etc.
>
> The concept is simple: given a domain, check its DNS, mail, etc.
> setup for correctness and consistency.  For example:
>
>   - does it have an A record?
>   - is that valid hostname?
>   - does it have an  record?
>   - is that valid hostname?
>   - does it have MX records?
>   - are the MX records *not* CNAMEs?
>   - are they valid hostnames?
>   - do those hostnames resolve to public IP addresses?
>   - are any of those MX records duplicates?
>   - are all the MX responding?
>   - are the MX weights valid?
>   - do all MX's pass FCrDNS check?
>   - does it have NS records?
>   - are they valid hostnames?
>   - do they have A,  records?
>   - are they in public IP space?
>   - are the NS records *not* CNAMEs?
>   - do all NS pass FCrDNS check?
>   - are any of those NS records duplicates?
>   - does the list of NS match the list of authoritative NS?
>   - do all the NS return the same list of NS?
>   - do all the NS return the same list of MX?
>   - do the NS *not* allow recursion?
>   - are any of the NS lame?
>   - are any of the NS missing?
>   - are all the NS responding?
>   - is there a working postmaster address?
>   - is there a working abuse address?
>   - is there a working hostmaster address?
>   - if not is there a working address that matches the one in the SOA?
>   - is the domain's SOA sane?  (e.g. plausible serial number,
>   refresh, retry, etc.)
>   - do all the NS return the same SOA with the same serial number?
>   - is there ASN diversity among the NS?
>   - and so on
There are plenty of tools for this.  Don't re-invent the wheel.

Here are a few (free) web-based tools (in no particular order); each has
its niche:

http://www.digwebinterface.com/
https://www.ssllabs.com/ssltest/
https://www.huque.com/bin/danecheck
https://dane.sys4.de/
https://mxtoolbox.com/ # many non-mx tests too
https://www.dnsstuff.com/
http://dnscheck.iis.se/
https://www.zonemaster.net/
http://dnsviz.net
https://www.ultratools.com/tools/asnInfo # and many other tools.
http://www.kitterman.com/spf/validate.html
https://www.dmarcanalyzer.com/ # Tools.  All but DMARC Analyzer are
free; it's freemium

Yes, there is a trend toward heavy UIs, but these are not frequent
tests.  If you set things up properly, it's not set and forget - but set
& validate changes need not be frequent enough to care.

If you maintain a few domains, it's not worth scripting.  If you
maintain a lot, the key is picking reputable providers for whatever you
don't do yourself.  If you have decent providers, there's not much for
you to monitor.  If you don't, you have bigger problems.

curl will let you script access to most, or you can use libraries such
as Perl's LWP, WWW::Mechanize::Firefox, WWW::Scripter, WWW::Selenium -
the last few support Javascript by running a browser.

It's better to maintain an interface to tests that someone else
maintains than to try to create & maintain all the tests - many seem
easy, but you'll find it becomes a serious time sink.  In the long term,
there is no such thing as a "small" P.roject.

> Those are the sort of checks that pertain to the operation of any domain
> and its nameservers and mail exchangers.  But in addition, if run on a
> Mailman 2 or 3 host:
>
>   - what mailing lists are public?
>   - what mailing lists are private?
>   - does every list have a working -request address?
>   - does every list have a working -owner address?
>   - does every list have a working -bounces address?
>   - if any list supports the optional -subscribe address,
>   does it have a -unsubscribe address?
>   - if any list supports the optional -join address,
>   does it have a -leave address?
>   - and so on
These are more interesting for mailman-users.  V3 has an API - but it
can be quite painful to navigate; I opened quite a few issues before
concluding that V3 isn't ready for (my) primetime.

V2 has some CLI tools in /usr/lib/mailman/bin - parsing output can get
you a lot of information.

In either case, it's not particularly interesting what Mailman THINKS is
configured; more things go wrong with bitrot in mailserver configuration
than in Mailman.  So you need to script something that actually tests
each action, receives list mail.  And while you (and I) may use the
CLIs, most users will use a GUI.  You have to test what the customer
uses.  So again, curl and company are your friends.

> Note: command-line tool.  It has to be, because then it can be scripted
> and run via cron and so on.  Besides, 

Re: [Mailman-Users] Brute force attacks on mailman web ui

[tlhackque via Mailman-Users]

On 16-Apr-18 07:38, Rich Kulawiec wrote:
> On Mon, Apr 16, 2018 at 09:08:43AM +0200, mailman-admin wrote:
>> Brute Force attempts can only be mitigated by e.g. fail2ban.
> Nope.  There are other ways.
>
> Brute force attacks can be pre-emptively blocked by nearly everyone
> operating a Mailman instance.  (I say "nearly" for specific reasons
> that will become clear below.)
>
> 1. You'll need a firewall, either in front of your Mailman instance
> or onboard the same system, that can handle a significant number of
> IP ranges in CIDR format.  I highly recommend "pf", which is part
> of OpenBSD (among others) and is easily the best firewall available.
> However, you can do this with other firewalls such as iptables just as 
> readily.
>
> 2. Get the Spamhaus DROP (Don't Route Or Peer) list, along with the EDROP 
> list:
>   
>   http://www.spamhaus.org/drop/drop.txt
>   http://www.spamhaus.org/drop/edrop.txt
>
> They're small.  Take a look at them.
>
> The DROP/EDROP lists are well-curated and consist of blocks that are
> known to be hijacked and known to belong to malicious actors.  You
> should *bidirectionally* block *all* traffic to/from the networks
> listed on them: HTTP, SMTP, DNS, everything.
>
> Update them by fetching new copies once a month.
Good advice.� But use httpS: (and make sure the UA validates the server
certificate).
Unless you fancy experimenting with DOS attacks.
> 3. The next step depends on the intended audience for your mailing
> lists.  If you're operating one for a bowling league in Akron, Ohio,
> then you probably don't need to accept subscription attempts from
> Peru, Pakistan, or Portugal.  If on the other hand you're operating
> one with global reach then you'll need a different approach.
>
> In either case, you'll want ipdeny.com's list of all network blocks
> by country:
>
>   http://ipdeny.com/ipblocks/data/countries/all-zones.tar.gz
>
> and you may want the Okean lists of blocks for China and Korea:
>
>   http://www.okean.com/chinacidr.txt
>   http://www.okean.com/koreacidr.txt
>
> (In theory, the list of CN and KR blocks in ipdeny's compilation
> should exactly match Okean's.  In practice, there are slight differences
> that tend to resolve over time.  I think if you're only configuring
> for CN and KR, use the latter; if you need more, use the former.
> But we'll get to that.)
>
> By the way, if you use these, you should update them once a month
> just like the DROP/EDROP lists.
>
> 3a. If your list is localized to one country or two or six, then
> use the ipdeny data to configure your firewall to block *all* HTTP traffic
> to your mailman instance and then only allow traffic from the countries
> that you need.  This usually takes a huge bite out of incoming abuse.
>
> 3b. If your list is global or nearly so in scope, then block as many
> countries as you can.  Look at your logs, see where the attacks are coming
> from, see where real subscriptions are coming from, and figure out the
> disjoint set. (The utility "grepcidr" is often very helpful.)
> If you have, let's say, zero subscriptions from FR over the past
> nine years but do have a parade of attacks: firewall it out.
>
> I recommend, in doing this analysis, that you start by looking at CN
> and KR.  Why?  Because two decades of careful logging and analysis
> of data from quite a few sites indicates that these are #1 and #2 on
> the hit parade of attackers.  There's no point in trying to file complaints
> in the hope that some responsible professional will take remedial action
> and make it stop: just firewall and forget.  (Next on the list are
> RU and IN.  Same problems.)
Yup.� And iran and afghanistan & the other former soviet countries.

But the biggest source of attacks, by far, is the US.� Unfortunately,
while some people run business that don't interact with the US, in most
cases a non-country based approach is necessary for that :-)

> Comment on 3a and 3b:
>
> Yes, this is draconian.  That's a good thing.  Let me quote for you what
> I think is arguably the best thing ever said on NANOG, and given the tens
> of thousands of years of accumulated network experience represented
> there, that's saying a lot:
>
>   If you give people the means to hurt you, and they do it, and
>   you take no action except to continue giving them the means to
>   hurt you, and they take no action except to keep hurting you,
>   then one of the ways you can describe the situation is "it isn't
>   scaling well".
>   --- Paul Vixie
>
> You can either get to work with a firewall or you can continue to be
> a victim.  Choose.
>
> If you want to continue to allow SMTP traffic from these countries
> so that users can subscribe/unsubscribe/etc. via mail that's your
> call.  I've tailored my configuration to suit the lists that I run
> and in some cases, that includes configuring the MTA to deny
> traffic from the same ranges as the web server; in others,
> it includes denying 

Re: [Mailman-Users] change links in mail footer to https

[tlhackque via Mailman-Users]

On 10-Dec-17 19:24, Mark Sapiro wrote:
>
> Note that with this specific issue, I could expose a list's web_page_url
> in the web admin UI, but that wouldn't solve the problem. As Brian
> indicates, making Mailman use https involve more than that. It also
> requires certificates and web server configuration, and while I don't
> know, I suspect these things require a server admin, even on cPanel.
>

I'm not going to claim cPanel expertise - but in my experience a cPanel
admin can allow server admins access to SSL/TLS configuration.  Once I
had that enabled, I was able to just paste certificates/keys into the
cPanel UI, and apache is reconfigured behind the scenes.  It's pretty
good about decoding the certificate and telling you what it covers and
when it's valid.  I have heard that there's a let'sEncrypt module for
cPanel (my provider doesn't have it yet).

So the missing piece for allowing a MM admin to convert to (or from)
https is 'just' the web admin UI - and some documentation.  (Note: I
don't run Mailman under cPanel, so I don't know what else there may be.)

Of course MM is mostly a volunteer effort, and MM2.1 is on the back
burner.  Didn't mean to imply otherwise.

As I noted, whether or not the web admin UI is improved for 2.1, it
should be done for 3.

And the doc should clearly indicate that shell access is (currently) a
requirement post-install.  Apparently, cPanel does some
packaging/wrapping of Mailman - which I can't speak to.  But there
should be no need for root access for a private Mailman instance running
from a user directory.  Mailman does not run under root.  If you choose
to run mailing lists for multiple administrative domains under a single
instance, you would need access to the instance's mailman user.  And
that could be undesirable and/or complicated. 

Off the top of my head, the only system file access required for MM2.1
is to /etc/aliases -- presumably, the cPanel wrapper takes care of
updating it (and running newaliases) as lists are created/destroyed.  As
I said, the best solution is to provide all the MM admin functions from
the web admin UI.  (There are quite a few in mailman/bin.)  Not just for
this, but because as time passes, fewer mailing list admins are
comfortable at the command line.

Speaking of WordPress - I do run it in a cPanel -managed host.  WP is a
completely private install.  My VirtualHost has a complete copy of
WordPress in my_username/public_html - nothing is stored in a system
directory.  And no root access is required.  From a hosting provider's
point of view, this isn't as efficient as a shared install.  But they
can charge for the disk space and network/computes used to update each
instance, so it works out.  I don't see why Mailman couldn't be packaged
the same way.  TLS is configured by editing the WP config file for each
instance (using the cPanel editor that I mentioned).  And certificates
are installed for the VirtualHost using cPanel->Security->SSL/TLS. 
(There are also plugins for getting certificates from various CAs.)

Finally, I never said "all shared hosting providers are bad".  I said
"many don't provide shell access", and that Mailman currently requires
it for a number of post-install admin operations.  It would be good if
those requirements could be reduced.  If someone has the
need/inclination/energy.

But this has gone rather far afield.  I don't have this particular
problem, so I'm going to leave this here.  I hope these notes help those
who do.


--
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] change links in mail footer to https

[tlhackque via Mailman-Users]

On 09-Dec-17 14:06, Mark Sapiro wrote:
> On 12/09/2017 10:40 AM, Chip Davis wrote:
>> That's all well and good Mark, but surely you know that any fix that
>> involves issuing a shell command is useless for those of us responsible
>> for lists on a shared server running cPanel (or equivalent).
>
> The OP indicated that he had changed DEFAULT_URL_PATTERN. If he can do
> that, he can run fix_url.

That is not necessarily true.

On a cPanel-managed website that I support, the "File manager" provides
an editor, which allows any text file to be edited.  And you can set 'x'
permission.  But there is no shell access, and no straightforward way to
execute a file.  (If you're clever and sufficiently motivated, you can
setup a temporary cron job or modify some source file.)

I've had similar issues with people using wiki software; in that case, 
the solution was to add a carefully-protected admin option to allow a
very privileged admin to run a shell command (e.g. system(...)).  As a
developer, I was not enthusiastic - but it seems that a significant
number of people are stuck with hosts that don't provide shell access. 
Of course, my first reaction was "change hosting provider" - but there
were many "I can't" - though the reasons varied.

You might consider adding a super-user menu to allow users to run
withlist; fix_url; etc without shell access.  Or an admin privilege that
can be granted to selected list managers.  If not for MM2, for MM3.

If you don't want to support mailman in environments without shell
access, at a minimum, put a big warning in the install docs that
"administration and maintenance of a mailman site requires shell
access".  It shouldn't be a requirement that's discovered later.




--
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] bulk subscribe 7K users

[tlhackque via Mailman-Users]

On 02-Oct-17 15:35, Dimitri Maziuk wrote:
> Oh, I agree: mailman worked exactly as designed. Whoever designed that
> particular assumed it'll take zero time to process an uploaded list of
> an unknown size, and that did precisely what ass-u-me always does. No
> surprises there, unfortunately.
No, the requirement was that you'd set the timeout on your webserver to
accommodate your environment.

The Mailman folks can't know what that is.  As the site administrator,
you are expected to.

E.g. for Apache, see the TimeOut directive, which is a balance between
preventing denial of service attacks, and letting long operations complete.

But if you want an (apparently) perfect hands-off experience, by all
means outsource to your IT department.  Then they'll be responsible for
the system-level analysis, implementation, and support.

If this is the case, I do not recommend Mailman V3.  Although it does
have an improved design, it still requires administration.  And despite
efforts by the developers, it is not yet as close to turnkey operation
as Mailman V2.1.  I'm sure it will be - eventually.  But it has a long
way to go.  Right now, it is more complex to setup, is missing features,
has no translations, and has more bugs.

From your comments on this thread, Mailman V3 will not (yet) meet your
expectations.


--
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] Recent phishing mails are targeting mailing-lists -- and do pass

[tlhackque via Mailman-Users]

SpamAssassin:

Don't match X-Spam-Score unless you are extracting the value and doing
computation.  Note that the value isn't necessarily numeric - e.g.
'undef - 10.0.0.23 is whitelisted' is a valid value, as are '-1.6 (-)',
'0.70 () [Tag at 5.00] COMBINED_FROM,SUBJ_YOUR_DEBT,SPF(pass,0)' and '0.00%'

Instead, match X-Spam-Level, which is designed for regex matching.

This will have a value of '*' for score 1, '**' for score 10, etc.

So match for the minimum score that you consider spam.  (Obviously, in a
regex, you have to quote the *).

E.g. '^\*\*\*\*\*\*\*\*\*' will match a score of 9 or higher.

On 26-Sep-17 09:23, Richard Shetron wrote:
> Spamassassin produces a numeric rating for for an email based on
> multiple rules.  Legitimate email can easily get a rating of 3 or 4
> based on the way you have it configured.  I've seen double digit
> ratings as well.  If you check for a single digit, you may be
> filtering legitimate emails that have a low score.
>
> On 9/26/2017 7:58 AM, Robert Heller wrote:
> [snip]
>>
>> I also use Spamassassin on my server, so having a rule like:
>>
>> "X-Spam-Score: \d"
>>
>> is also helpful at catching spam and phishing mail.
>>
> [snip]
>

--
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] Correct Mailman setup

[tlhackque via Mailman-Users]

On 22-Sep-17 16:50, Mark Sapiro wrote:
> At Fri, 22 Sep 2017 17:57:36 +0200 lusche...@yahoo.de wrote:
>>>
>>> Hi all
>>> [Snip]
>>> , but every now and then some people
>>> complain about something. The most annoying thing is that messages are
>>> processed but then queued for up to one hour before they go out. The
>>> mail system is on the same virtual server, and the provider has no idea
>>> what to do. Otherwise the mail server does not ause problems, any
>>> message submitted normally (not via Mailman) goes out nearly instantly. 
>>> I would appreciate if a knowledgeable person could guide me through the
>>> proper setup of these lists.
> [Snip]
>
> What I can tell you is there is nothing in normal list configuration
> that would cause delays in outgoing mail. The most likely cause of these
> delays is Mailman's 'out' queue being backlogged. There are multiple
> posts about this in this list's archives including
> .
> There is also a FAQ at .
>
> One thing you can check is if posts are archived almost immediately even
> though they aren't sent out for some time. This indicates a possibly
> backlogged 'out' queue or possibly other delays in outgoing mail. If the
> posts are not archived until they are ultimately sent out, that would
> indicate the delay is in incoming mail.

> It is also possible the outgoing mail server is throttling mail, i.e.
> limiting the number of messages sent per hour or some such.
Another common cause is that the RECEIVER is using 'greylisting'.  This
is an anti-spam
technique that some believe is effective.  The receiver sends a
"temporary failure"
when e-mail is received from an unknown or "suspicious" source.  If the
sender retries
in a "reasonable" window, it goes through.  Typically a delay of 15-30
minutes but not
more than a few hours works.  The theory is that spammers won't bother
to retry.
Usually subsequent e-mails from the same source go through without delay
- for a while.

Also, MTAs have timeouts - a common configuration is for the sending MTA
to attempt
sending with a short timeout for connect/greeting/helo response.  If
this times out,
the message is queued for a later attempt with longer timeouts.  The
reasons are that
some RECEIVERs intentionally delay responses to SMTP commands in the
belief that
spammers won't wait (or retry).  The sending MTAs with dual timeouts
don't want
these receivers to slow delivery to "normal" destinations.

If either of these is the case, the sending MTA may be running its queue
hourly.
Running it every 30 minutes may help.  Contacting the receivers to
whitelist your
sending IP may help. 

And there are various e-mail reputation services that will whitelist (or
blacklist)
senders.  Whitelisted senders may bypass greylisting.

All these are under the control of the operator of your sending MTA;
they happen
after Mailman has queued the mail.

For more on greylisting, see https://www.greylisting.org/ (or just do a
web search
on e-mail greylisting.
> The bottom line is if the hosting service won't help you with this,
> you're stuck. 
Unless you find someone willing to let you use a better-configured outgoing
mail server, or you run your own (which is not for the faint-hearted).

> You might find
>  of some interest.
>
> If there are other issues/complaints, please describe both the current
> and desired behaviors, and perhaps we can offer more advice.
>

--
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 blocking malicious subscription requests?

[tlhackque via Mailman-Users]

On 05-Sep-17 10:55, Ian Kelling wrote:
> There is at least one very major mail provider where
> joe+any_string@domain goes to the inbox of joe by default, allowing bad
> people to get my mailman instance to send many subscription mails to
> joe+random_string@domain, messing up joe's inbox, because mailman just
> sees different addresses. Can mailman stop doing this? If not, I'm open
> to an exim rule to block or at least rate limit mailman from doing this
> too.
This is correct behavior by both the mail service provider and by mailman.

The way to address the anti-social behavior described is to implement a
captcha, which
will effectively rate-limit subscription requests by bad actors -
usually to close to zero.

This has been discussed recently on this list.
> Also, is there a way to rate limit subscription requests even for the
> exact same email address? For example, don't allow someone to subscribe
> to list b if they have > 5 unconfirmed subscription requests in the last
> day?
I don't think so, but others more expert may respond.  If not, it seems
like a reasonable
feature request for MM3.  But a captcha will probably have the effect
that you want.

I use reCAPTCHA (now hosted by Google).  It seems to stay ahead of the
captcha-solver bots
most of the time.  It's important to choose one that is accessible to
people with disabilities.
> --
> Ian Kelling | Senior Systems Administrator, Free Software Foundation
> GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
> https://fsf.org | https://gnu.org
>

--
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] Distributed mass subscribe attack?

[tlhackque via Mailman-Users]

On 17-Aug-17 16:47, Andy Cravens wrote:
>
>
> David,
>
> I forgot to mention I’m also working on a modsecurity rule to look at all 
> POSTs
> and reject if they contain an email address with a + sign.
>
I understand the drive to suppress an attack.  However, + is valid in
e-mail addresses.  It's frequently used by people to setup auto-filing
rules, and/or to track the source of addresses harvested for SPAM.

I strongly discourage any service provider from defining what formats of
e-mail addresses are acceptable.  Such definitions, however
well-intentioned, are almost always wrong - and effectively blindly deny
service.

We've seen this with hardcoded lists of TLDs (there'll never be more
than 13.  + CC TLDs. + IDN + freemarket...).  And every variety of
mailbox name format restriction - character set, length, "bad words", ...

If an address is valid per RFC822 (2822,5322, ...), accept it.

But by all means use other approaches to suppress attacks.  Captchas are
probably your best shot.  Rate limiting can help.  You can use
(imperfect) filtering by geolocating by IP address - if your client base
doesn't include the whole world.   Other tricks include telling the user
to wait a minute or two before clicking submit; discard or require
re-submission of early responses.  Bots won't do that. 

No matter what you do, the spammers will adapt, eventually.  But unless
you're a particularly appealing target, they're likely to move on if you
do almost anything unusual.

--
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 3 confusion

[tlhackque via Mailman-Users]

> /home/ubuntu/mailman/var/etc/mailman.cfg`
> 10. Logs are in ~/mailman/var/logs
>
> It is not a straightforward install process and requires a little
> detective work based on your environment and mail server. I had the
> disadvantage of never being a Mailman 2 user, so a big chunk of my
> learning curve was understanding Mailman terminology and its way of
> doing things.
>
> I still do not have Postorius or Hyperkitty installed. My use case is
> a PHP-based CMS which administers Mailman 3 Core via its REST API. I
> wrote a quick and dirty PHP client and it works surprisingly well.
> Mailman 3 Core has been solid in production and easy to deal with via
> the REST API.
>
> Good luck, and you might want to check out the Mailman 3-specific
> users list
> here: https://lists.mailman3.org/archives/list/mailman-us...@mailman3.org/
>
> On Sat, Jun 17, 2017 at 5:14 PM, tlhackque via Mailman-Users
> <mailman-users@python.org <mailto:mailman-users@python.org>> wrote:
>
> I took another look at installing Mailman 3, and ended up lost and
> confused.  I'm an experienced software person - but my Python
> knowledge
> is minimal.
>
> Fedora 25, python 3.5.3, pretty much out of the box.
>
> Mailman version: 3.1.0 (The other bits and pieces are current - 1.1)
>
> I tried to follow the documentation on
> http://docs.list.org/en/latest/prodsetup.html
> <http://docs.list.org/en/latest/prodsetup.html>,
>
> 
> http://mailman-3-installation.readthedocs.io/en/latest/production_install.html
> 
> <http://mailman-3-installation.readthedocs.io/en/latest/production_install.html>
> claims that the backend requires Python 3.4, but the frontend
> 2.7.  Not
> clear if this is credible, but it's out there...
>
> https://wiki.list.org/Mailman3 points to Mark Sapiro's experience on
> https://wiki.list.org/DOC/Mailman%203%20installation%20experience
> <https://wiki.list.org/DOC/Mailman%203%20installation%20experience> 
> This
> starts off with "For both installs I started with mailman-bundler."
> But https://gitlab.com/mailman/mailman-bundler
> <https://gitlab.com/mailman/mailman-bundler> says "All of this
> documentation is obsolete!  Mailman Bundler is no longer
> recommended or
> supported. "  So...
>
> I have yet to find a step-by-step 'bare OS to running MM3" document.
> I've run MM2.1 lists for years, it wasn't this hard to get started.
> Just install and edit one config file (plus the webserver.).  I don't
> want to learn a zillion other technologies just to get started - e.g.
>
> But, I decided to see how far I could get.  I tried this, based on pip
> search mailman:
>
> dnf install python3 python3-devel (gets 3.5.3)
> pip3 install mailman postorius mailmanclient HyperKitty
> mailman-hyperkitty KittyStore
>
> All went well until KittyStore, which (0.9.3 is what pip found)
> died with:
> Collecting storm (from KittyStore)
>   Downloading storm-0.20.tar.bz2 (213kB)
> 100% || 215kB 318kB/s
> Complete output from command python setup.py egg_info:
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/tmp/pip-build-wzs03r_4/storm/setup.py", line 5, in
> 
> import ez_setup
>   File "/tmp/pip-build-wzs03r_4/storm/ez_setup.py", line 106
> except pkg_resources.VersionConflict, e:
> ^
> SyntaxError: invalid syntax
>
> Well, set that aside, and install the rest, which seems to work.
>
> Try again with KittyStore, same failure.  So maybe skip the
> archive for now.
>
> Try 'mailman info', another syntax error.
>
> Traceback (most recent call last):
>   File
> "/usr/lib/python3.5/site-packages/zope/configuration/xmlconfig.py",
> line
> 272, in endElementNS
> self.context.end()
>   File
> "/usr/lib/python3.5/site-packages/zope/configuration/config.py",
> line 345, in end
> self.stack.pop().finish()
>   File
> "/usr/lib/python3.5/site-packages/zope/configuration/config.py",
> line 452, in finish
> args = toargs(context, *self.argdata)
>   File
> "/usr/lib/python3.5/site-packages/zope/configuration/config.py",
> line 794, in toargs
> args[str(name)] = field.fromUnicode(s)
>   File
> "/usr/lib/python3.5/site-packages/zope/configuration/fields.py",
> line

[Mailman-Users] Mailman 3 confusion

[tlhackque via Mailman-Users]

I took another look at installing Mailman 3, and ended up lost and
confused.  I'm an experienced software person - but my Python knowledge
is minimal.

Fedora 25, python 3.5.3, pretty much out of the box.

Mailman version: 3.1.0 (The other bits and pieces are current - 1.1)

I tried to follow the documentation on
http://docs.list.org/en/latest/prodsetup.html,

http://mailman-3-installation.readthedocs.io/en/latest/production_install.html
claims that the backend requires Python 3.4, but the frontend 2.7.  Not
clear if this is credible, but it's out there...

https://wiki.list.org/Mailman3 points to Mark Sapiro's experience on
https://wiki.list.org/DOC/Mailman%203%20installation%20experience  This
starts off with "For both installs I started with mailman-bundler."  
But https://gitlab.com/mailman/mailman-bundler says "All of this
documentation is obsolete!  Mailman Bundler is no longer recommended or
supported. "  So...

I have yet to find a step-by-step 'bare OS to running MM3" document. 
I've run MM2.1 lists for years, it wasn't this hard to get started. 
Just install and edit one config file (plus the webserver.).  I don't
want to learn a zillion other technologies just to get started - e.g.

But, I decided to see how far I could get.  I tried this, based on pip
search mailman:

dnf install python3 python3-devel (gets 3.5.3)
pip3 install mailman postorius mailmanclient HyperKitty
mailman-hyperkitty KittyStore

All went well until KittyStore, which (0.9.3 is what pip found) died with:
Collecting storm (from KittyStore)
  Downloading storm-0.20.tar.bz2 (213kB)
100% || 215kB 318kB/s
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
  File "", line 1, in 
  File "/tmp/pip-build-wzs03r_4/storm/setup.py", line 5, in 
import ez_setup
  File "/tmp/pip-build-wzs03r_4/storm/ez_setup.py", line 106
except pkg_resources.VersionConflict, e:
^
SyntaxError: invalid syntax

Well, set that aside, and install the rest, which seems to work.

Try again with KittyStore, same failure.  So maybe skip the archive for now.

Try 'mailman info', another syntax error.

Traceback (most recent call last):
  File
"/usr/lib/python3.5/site-packages/zope/configuration/xmlconfig.py", line
272, in endElementNS
self.context.end()
  File "/usr/lib/python3.5/site-packages/zope/configuration/config.py",
line 345, in end
self.stack.pop().finish()
  File "/usr/lib/python3.5/site-packages/zope/configuration/config.py",
line 452, in finish
args = toargs(context, *self.argdata)
  File "/usr/lib/python3.5/site-packages/zope/configuration/config.py",
line 794, in toargs
args[str(name)] = field.fromUnicode(s)
  File "/usr/lib/python3.5/site-packages/zope/configuration/fields.py",
line 73, in fromUnicode
value = self.context.resolve(name)
  File "/usr/lib/python3.5/site-packages/zope/configuration/config.py",
line 151, in resolve
mod = __import__(mname, *_import_chickens)
  File "/usr/lib/python3.5/site-packages/mailman/database/factory.py",
line 22, in 
import alembic.command
  File "/usr/lib/python3.5/site-packages/alembic/command.py", line 3, in

from .script import ScriptDirectory
  File "/usr/lib/python3.5/site-packages/alembic/script/__init__.py",
line 1, in 
from .base import ScriptDirectory, Script  # noqa
  File "/usr/lib/python3.5/site-packages/alembic/script/base.py", line
2, in 
from dateutil import tz
  File "/usr/lib/python3.5/site-packages/dateutil/tz.py", line 78
`self._name`,
^
SyntaxError: invalid syntax

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/mailman", line 9, in 
load_entry_point('mailman==3.1.0', 'console_scripts', 'mailman')()
  File "/usr/lib/python3.5/site-packages/mailman/bin/mailman.py", line
97, in main
initialize(config_path)
  File "/usr/lib/python3.5/site-packages/mailman/core/initialize.py",
line 184, in initialize
initialize_1(config_path)
  File "/usr/lib/python3.5/site-packages/mailman/core/initialize.py",
line 101, in initialize_1
xmlconfig.string(zcml.decode('utf-8'))
  File
"/usr/lib/python3.5/site-packages/zope/configuration/xmlconfig.py", line
513, in string
processxmlfile(f, context)
  File
"/usr/lib/python3.5/site-packages/zope/configuration/xmlconfig.py", line
295, in processxmlfile
parser.parse(src)
  File "/usr/lib64/python3.5/xml/sax/expatreader.py", line 110, in parse
xmlreader.IncrementalParser.parse(self, source)
  File "/usr/lib64/python3.5/xml/sax/xmlreader.py", line 125, in parse
self.feed(buffer)
  File "/usr/lib64/python3.5/xml/sax/expatreader.py", line 210, in feed
self._parser.Parse(data, isFinal)
  File "/builddir/build/BUILD/Python-3.5.3/Modules/pyexpat.c", line 468,
in EndElement
  File "/usr/lib64/python3.5/xml/sax/expatreader.py", line 370, in
end_element_ns