[Mailman-Users] Non-delivery of approved messages
Francis Jayakanth via Mailman-Users writes:
> The list is running on Mailman 2.1.26.
If possible you should upgrade Mailman, currently at version 2.1.39.
Almost all of the releases since 2.1.26 are primarily oriented to
"security" and "reliability" issues. I don't recally any offhand that
would help alleviate your current problem, but who knows? And the
changes address genuine vulnerabilities that have been exploited at
many sites in the past.
> During the last couple of weeks, approved messages are not being
> delivered to the list members. When I check the Email &
> collaboration alerts in the Microsoft 365 Admin Portal, I see the
> following message:
Do you mean that Microsoft provides the email services to your
organization or to a host that your organization uses, and they're not
letting *your* traffic go out to *anyone*? That's a new one to me.
"Shocked but not surprised", as the saying goes.
Your problem is with Microsoft. You need to get their help,
especially if they are providing your email services. They do not
tell us why they block some messages or some users rather than others,
and it often seems completely random. Here it sounds like the
"suspicious activity" is sending lots of mail to many addresses. Ie,
you're being throttled *because* you're running a mailing list. But
you'll have to negotiate with them if that's what's happening.
The generic recommendations are
1. Get your users off Google, Yahoo, Verizon, and Office365. Yeah, I
know that's "impossible", but it's the single most effective
method for improving the experience of mailing list subscribers.
2. If you manage your own mail system, make sure your DNS records for
SPF and DKIM are in order, and that your MTA is configured to sign
messages properly. If somebody else is responsible for that, ask
them to check and fix any problems. (This applies to 3 throuhg 7
below, too.)
3. Implement DMARC on your system. This doesn't have a standards-
based effect on posters whose email accounts are not on your host,
but it may enhance your site's general reputation.
4. Implement the ARC (Authenticated Received Chain) protocol. The
basic idea is that any change your mailing list makes such as
adding list tags to the Subject or an organizational footer to the
body of the mail will break the DKIM signature that attests that a
valid user on the original sending system (the author or "From"
address) sent the mail. ARC allows you to say (in a way that some
email software understands) "We validated this message, the
signatures were in order, and if it turns out to be spam or
whatever you can blame us. Here's our signature so you can
believe it." I don't know offhand if Microsoft implements it or
if they put much weight on it, but it can't hurt. Google and
Yahoo do put a fair amount of trust in it, I'm told.
The following advice is generally good, but it may not be influencing
your current problem.
5. Put spam filters on your *outgoing* mail. Folks are of two minds
about this (if you're primarily a mailing list site and you filter
incoming, you won't catch anything new going out), but sometimes
you can catch things going out that you wouldn't catch coming in.
This is especially true if you use Bayesian or "machine
learning"-based spam filters so you can use experience to tell
them in the context of the mailing list whether it's spam or not.
6. Check your moderation queues ("held messages") for unusual amounts
of spam -- some of it may be getting through to your subscribers.
7. Check the subscription queues ("awaiting address confirmation")
for an unusual number or a pattern of particular addresses being
subscribed to a large number of unrelated lists. Unfortunately,
the confirmation process can be abused by malicious third parties
to send large numbers of address confirmation notices to unrelated
addresses, thus clogging their mailboxes. Not only is this
annoying and even a denial of service to the victims, but it also
can hurt your site's reputation.
I'm sorry I can't be of more help, but the large providers are far
more sensitive to any spam that gets through than they are to lost
mail, because they can blame lost mail on the sender, while users
hold them responsible for spam.
Regards,
Steve
--
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: Security features of Mailman
Steven, Juergen, et al, I had written most of this but interrupted, then Jurgen's email came in, so... this got an edit! If a spot or two seems awkward it's because of available time. On Mon, 5 Feb 2024, Stephen J. Turnbull wrote: Thanks for your followup. Although you suggested taking the conversation private, I want to at least continue for one more post because it's not clear to me that there's demand for this service that is enough to justify the likely substantial cost of development. I don't know how to implement poster-to-subscriber encryption It's very straight-forward: Public Key Encryption is used: Subscribers who want encrypted email include their public key in their subscription details, just as they include their name and digest type choices. The list itself, for its reception, uses TLS. The outbound, from list server to subscriber is where "the magic happens," encrypting the outbound to each user using their own public key. And then Juergen, as if on cue, added: on Tue, 6 Feb 2024, Juergen Dollinger wrote: We tried encrypted lists some years ago. Have a look at http://non-gnu.uvt.nl/mailman-pgp-smime/ The idea is that there is a key for the list, the server decrypts the E-mails and encrypts it for the recipients who have supplied a key. Worked fine with that old version of Mailman 20 years ago. But even in our quite nerdy environment only about the half of the subscribers submitted a key for the list. (excuses are like 'I want to use grep(1) for fulltext search in my list E-mails') So after the next mailman update we dropped the patch and run unencrypted again. I was unaware of this and I would have latched on with both hands! Note that 20 years ago people, on whole, were less aware of the issues with unencrypted emails and that HALF DID sign up is rather amazing. Most users 20 years ago had "grown up with" a very friendly internet and remembered those times without perceiving the risks, while the newcomers were clueless to pretty much everything. Therefore the aprox. 50% number is amazing. HOWEVER, just becasue ONE email list of a group who realized it was there had that experience says NOT A THING about how many who didn't know would love to have a list where users HAD to use encryption to be on the list! Consider that the safest email is one in which sender and recipient are on the same system, MANY corporate environs would likely LOVE to have the added flexibility and security that could come from having an email list with this capability used for communications with not just employees but their vendors. It's myopic to see just one's own use case and think it applies across the board. Moving on, Steve goes on to say: on the one hand, and on the other hand most list owners are unable or unwilling to manage their own hosts, and therefore have to provide the ability to decrypt list traffic to a third party. Over my long and storied 47 year career in computer science I've long noted that the vast majority of users: 1) Don't know what they really want; 2) Don't have a clue what's easy and what's hard, and; 3) Don't hang out on email lists like this one. (BTW the vast majority of project managers fit this same profile and explains why we get such atrociously bad software sometimes, even from gifted teams; if management is ignorant, it leads to less-than-optimal results, especially with autocratic leadership that doesn't trust their teams or want their creativity or input. But I digress...) Steve: But I could be quite wrong, and it's the members of the Mailman community who are most likely to provide a critical mass of users to say "that's just what I've always wanted, and here are the features I want". If that critical mass doesn't show up, then I want to use my time (and resources such as summer interns) on features that our community *does* want. The fact that nobody but you has raised their hand to say "I want this" or "my list owners would really like this" is not a point in its favor. Your argument isn't any better. The a majority of users have no clue that their emails are vulnerable in transit on the internet, much less as a separate risk from their email provider. So if it's your idea that we don't offer people the chance for better and only focus on giving people what they already know they want, progress is ... "suboptimal." However, let me say to anybody who has read this far that although I have played and continue to play the devil's advocate against "privacy-preserving mailing lists", I want everybody to understand that I am very much in favor of privacy. Good. But there are substantial technical hurdles to extreme requirements such as "end-to-end encryption" of list traffic. That is abjectly false, Juergen proved it, and not only was it NOT difficult 20 years ago, in the 20 years since then what's fairly easily possible has expanded considerably. BTW, that one of us doesn't know how
[Mailman-Users] Re: Security features of Mailman
Stephen J. Turnbull wrote: > The fact that nobody but you has raised their hand to say "I want > this" or "my list owners would really like this" is not a point in its > favor. We tried encrypted lists some years ago. Have a look at http://non-gnu.uvt.nl/mailman-pgp-smime/ The idea is that there is a key for the list, the server decrypts the E-mails and encrypts it for the recipients who have supplied a key. Worked fine with that old version of Mailman 20 years ago. But even in our quite nerdy environment only about the half of the subscribers submitted a key for the list. (excuses are like 'I want to use grep(1) for fulltext search in my list E-mails') So after the next mailman update we dropped the patch and run unencrypted again. -- \ J. Dollinger FAW/n Ulm |zeitnot@irc| http://www.home.pages.de/~zeitnot/ \"What're quantum mechanics?" -- "I don't know. People who/ \repair quantums, I suppose." (Terry Pratchett, Eric) / -- 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...@mail-archive.com
[Mailman-Users] Non-delivery of approved messages
Hi, I administer and moderate a library and information science professional list. The list is running on Mailman 2.1.26. There are nearly 5k list subscribers, of which almost 4k are 'digest' registrants. The majority of the registrations are with personal email IDs. During the last couple of weeks, approved messages are not being delivered to the list members. When I check the Email & collaboration alerts in the Microsoft 365 Admin Portal, I see the following message: Suspicious email sending patterns detected, User was restricted from sending emails. Additionally, a pop-up on the screen reads: "Unblock entities which have been blocked for sending too many messages marked as spam/bulk." The first approved message gets delivered after unblocking the relevant email ID and approving another message after 24 hours. For the subsequent one, the emails bounced back, and the MS admin portal reported the same error messages mentioned above. Can someone please help me fix this issue? Thank you for your attention and time, Francis -- 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...@mail-archive.com
