Florin Pasăre writes: > Hello, > I've been having some issues lately. We are using Mailman 2.1.15.
Mailman 2.1.15 was released in 2012, ie, long before the AOL/Yahoo "contact list leak" fiasco. This means your lists are unable to dealwith anti-phishing and anti-spam measures adopted by many sites (and specifically AOL and Yahoo and their successor operators). You should upgrade to the most recent Mailman 2 for now, and strongly consider upgrade to Mailman 3 in the near future. (Both Mailman 2 and Python 2 are long since "end of life", and increasingly vulnerable to attack as they are not being actively developed.) Make sure you check the upgrade notes for any special procedures and requirements for supporting software. Recent Mailman provides a large number of important new features. Most important, many recipient sites participate in the DMARC and ARC protocols. The important aspect of DMARC is that a site can declare that emails with "From" address in that domain MUST have a valid DKIM signature from that site (called "From alignment"), otherwise the recipient should reject or discard the email. Because mailing lists frequently make changes such as appending footers to the body and prepending list tags to Subject which invalidate DKIM signatures, From alignment will fail on all mailing lists messages. I cannot be sure without more information whether your users are running into this problem, but it's usually pretty obvious even to non-experts, because mail from a person at site X starts bouncing for everybody at several sites. Recent Mailman provides two options to deal with this. The first is to rewrite the address in From from 'John Doe <john....@example.com>' to something like 'John Doe via Your List <your-l...@your-site.org>' for all posts passing through the list. The second is to do the same rewriting, but only for sending domains which publish a "please reject" policy. These are both per-list options. It also provides a number of other security improvement, in particular protection against cross-site scripting. The ARC protocol deals with the From alignment problem in a different way. Each participating mail gateway validates the DKIM signature, adds information about the result to the mail, and digitally signs that information. So this basically amounts to each gateway testifying that "everything was OK when it got to me, I made some changes and signed them, check that." Of course this depends on the final recipient trusting intermediary who makes changes, but in most cases that's only your list. Mailman 2 doesn't provide ARC, but ARC is best implemented in the MTA. Mailman 3 does have an implementation, but we still recommend doing it in the border MTAs as defined by the ARC RFC. Note that the two DMARC "From" modifications and ARC are all substitutes for each other, with differing advantages and disadvantages. You can get both DMARC features just by upgrading Mailman 2, which you should do anyway to improve the overall security of the Internet. To get ARC, you need to install additional software to your MTAs (or upgrade all the way to Mailman 3). > in the last months the number of bounces we get has increased. We > receive these bounce notifications informing us that the given > *subscription has been disabled* due to *excessive or fatal bounces > *(up to around 30 bounce notifications triggered by a single email > sent to one of the listservs). [Disclaimer: "Listserv" is the trademark of a commercial mailing list manager owned by L-Soft, and should not be used to refer to Mailman installations.] I'm not sure why you would experience an uptick more recently than say 2014-2016 when many mail servers adopted stricter policies toward malicious mail. > Every time we get such notifications, we untick the bounce under > “nomail [reason]" in the admin management site for each of the > email addresses that haven been disabled by the system. If these are people who are regularly reading their email, this is a somewhat dangerous policy. They're just going to get disabled again, and perhaps unsubscribed. In the meantime, they're losing mail. You really need to investigate why these bounces are happening. By far most delivery failures these days are due to recipient site policy, not equipment or software failures. Occasionally inattentive users exceed mailbox allocations, but that's not so common in these days of freemail providers with default 10GB allocations. What more can you do? First, get list owners to check for "Delivery Status Notifications" (DSNs). These often explain in more or less plain language why the mail was rejected. Often it's because it was considered spam or phishing (the less plain language is "administratively prohibited"). In that case it's very likely your posts will get caught frequently. Second check both the Mailman logs (usually in some directory like /var/lib/mailman/logs) and the MTA logs. MTA logs are usually in directories like /var/log/$MTA_NAME, but also may be in /var/log/mail.log or even the syslog. If the problem is not obvious, don't hesitate to ask us about them. However, when you do, please provide us with all the logs and DSNs pertaining to a particular rejected message. Do provide the entire log message, including timestamp. You probably should post such requests to *this list*, because the developers are not necessarily the best people to interpret them, and we are a small group. Often you will get the best advice from other users who have had similar experiences. Please check any materials you forward to this list for user logins and passwords and redact them. (There shouldn't be any, but ....) If you are concerned about revealing information about your internal network configuration, feel free to redact domain names, IP addresses, and email addresses. However, they should be recognizable as what they are (use "example.com", "10.1.2.3", and "john....@example.com", not "REDACTED"), Also, each unique entity should received a unique substitution consistently. For domains, "example.com", "example.org", and "example.net" (at least, there may be others) are "black hole" sites registered by the IETF (I think) for use in documentation, so they won't be confused with real domains. Similarly, I recommend IPs be substituted with dotted-quads starting with "10.", because those IPs are defined to be private and unreachable from the public Internet. Alternatively, if you need to explain sensitive details about your systems you can write to me and Mark Sapiro personally. > Furthermore, it has happened several times in the past few months > that a number of email addresses have been automatically removed > from the listservs (at the same time, from different countries). This is part of a normal process. When Mailman receives a bounce, it increments the bounce count for that address. If the bounce count is lower than the disable level, it will continue to try to send messages to that address (and no more bounces are counted for 24 hours). Once it reaches the disable level, the subscription is disabled. If Mailman continues to receive bounces for that address, eventually the address will be unsubscribed. List owners can tune this process by setting the number of bounces for the disable and unsubscribe levels, as well as the number of days with no bounces until the bounce count gets set to zero. > We have not found an explanation for why this happens or a > solution, so the only thing we are able to do is to manually add > them back to the listservs. There are several reasons why Mailman might continue to send list- related traffic to a disabled address, but this reflex of reenabling disabled addresses without solving the underlying problem is definitely one. Of course, there's not much else you can do if you're not an expert. But please, in the future, when your own systems are denying service to your users, *do* come talk to us (or whoever the vendor is) as soon as you realized it's a recurring problem. Also, please note that Mailman distinguishes between hard bounces, where some server said "we will never accept this message for this address", and soft bounces, where the server said "we can't accept this message now but please try again later". The MTA (usually) or sometimes Mailman does exactly that: it adds the message to a "retry" queue and tries again. Hard bounces, on the other hand, means that the message was never delivered to that subscriber. Your users are losing email. ------------------------------------------------------ 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
