Hi Jeremy and Everyone,
Jeremy Bryant wrote:
> Hi Savannah hackers,
>
> I wish to stay subscribed to bug-gnu-em...@gnu.org however the server
> periodically unsubscribes me due to 'excessive bounces'. Can you
> investigate what the cause might be?
>
> I have no such problems with emacs-devel itself.
>
> Thanks in advance for any technical ideas!
Jeremy also sent this to the mailing list -owner address to reach the
human sysadmins of the list and I read that message first and already
responded there. But not wanting to keep people here in the dark let
me copy-paste what I wrote there over here too. I'll slightly modify
this version with additional thoughts that appeared in my head since
the original.
I am just one of several on the team but I will apologize for having
been gone for a while and just now getting to your note. We are all
volunteers and sometimes there is simply no one available for extended
comments. (I was offline for more than a week on travel.)
> Unfortunately the list software has rejected my email address, although
> I don't understand why. Could a sysadmin explain what the 'excessive
> bounces' is so I can fix it?
Mailman keeps track of how many bounces have occurred per recipient.
If there are too many bounces then Mailman will unsubscribe the
address from the mailing list. But a single bounce is never enough to
trigger this action. The algorithm is counts up bounces per day that
there is a bounce and decrements on days without bounces. And this
also depends upon the traffic volume of the mailing list.
Here is what Mailman itself says. Better than my paraphrasing.
Bounce processing
These policies control the automatic bounce processing system in
Mailman. Here's an overview of how it works.
When a bounce is received, Mailman tries to extract two pieces of
information from the message: the address of the member the message
was intended for, and the severity of the problem causing the
bounce. The severity can be either hard or soft meaning either a fatal
error occurred, or a transient error occurred. When in doubt, a hard
severity is used.
If no member address can be extracted from the bounce, then the bounce
is usually discarded. Otherwise, each member is assigned a bounce
score and every time we encounter a bounce from this member we
increment the score. Hard bounces increment by 1 while soft bounces
increment by 0.5. We only increment the bounce score once per day, so
even if we receive ten hard bounces from a member per day, their score
will increase by only 1 for that day.
When a member's bounce score is greater than the bounce score
threshold, the subscription is disabled. Once disabled, the member
will not receive any postings from the list until their membership is
explicitly re-enabled (either by the list administrator or the
user). However, they will receive occasional reminders that their
membership has been disabled, and these reminders will include
information about how to re-enable their membership.
You can control both the number of reminders the member will receive
and the frequency with which these reminders are sent.
There is one other important configuration variable; after a certain
period of time -- during which no bounces from the member are received
-- the bounce information is considered stale and discarded. Thus by
adjusting this value, and the score threshold, you can control how
quickly bouncing members are disabled. You should tune both of these
to the frequency and traffic volume of your list.
And then the current settings for the bug-gnu-emacs list are these
following settings.
Should Mailman perform automatic bounce processing? Yes
Each subscriber is assigned a bounce score, as a floating point
number. Whenever Mailman receives a bounce from a list member, that
member's score is incremented. Hard bounces (fatal errors) increase
the score by 1, while soft bounces (temporary errors) increase the
score by 0.5. Only one bounce per day counts against a member's score,
so even if 10 bounces are received for a member on the same day, their
score will increase by just 1. This variable describes the upper limit
for a member's bounce score, above which they are automatically
disabled, but not removed from the mailing list.
The maximum member bounce score before the member's subscription
is disabled. This value can be a floating point number. 14.0
The number of days after which a member's bounce information is
discarded, if no new bounces have been received in the
interim. This value must be an integer. 7
How many Your Membership Is Disabled warnings a disabled member
should get before their address is removed from the mailing
list. Set to 0 to immediately remove an address from the list once
their bounce score exceeds the threshold. This value must be an
integer. 3
The number of days between sending the Your Membership Is Disabled
warnings. This value must be an integer. 7
Should Mailman send you, the list owner, any bounce messages that
failed to be detected by the bounce processor? Yes is recommended.
Yes
Should Mailman notify you, the list owner, when bounces cause a
member's bounce score to be incremented? No
Should Mailman notify you, the list owner, when bounces cause a
member's subscription to be disabled? No
Should Mailman notify you, the list owner, when bounces cause a
member to be unsubscribed? No
For high volume lists, and bug-gnu-emacs is fairly high volume, we can
count on having message traffic every day. If bounces are received
every day then after 14 days the address will be disabled. If no
bounces are received after 7 days then everything is discarded
resetting back to the start state. (For low volume lists of say one
message a week then there can never be enough bounces to disable any
account even if every message bounces.)
The default bounce_score_threshold is 5.0 so seeing 14.0 there tells
me that someone has already increased that threshold in order to make
it less likely that someone with transient bounce problems will be
disabled. It still disables accounts that always bounce messages
though.
Your email @jeremybryant.net appears to be handed by 123-reg.co.uk
hosted at Webfusion hosting. If they are handling your email then
they would be the ones bouncing messages from the mailing list. You
might contact them and see if they can say why they are bouncing
messages? Perhaps have them put lists.gnu.org into an allow list to
avoid bounces in the future?
For a period of time now mitigated it was strict DMARC settings from
various email service providers used by subscribers which caused
bounces. For example a very popular European freemail provider set
strict DMARC which prevented forwarding through mailing lists. These
messages were then correctly bounced by Google for all Gmail
subscribers. The effect was that Gmail users were unsubscribed due to
those bounces that were caused by this *other* freemail provider! Law
of unintended consequences there for sure.
My opinion is that strict DMARC is very useful for banks and financial
institutions which do not want their email forwarded but should NOT be
used for persons. Obviously there is disagreement on this issue
because they are doing it regardless. This has been mitigated by
having Exim on the GNU mail servers modify the From: address to be the
mailing list in this case. Many people do not like seeing "via" the
mailing list but the sender has given no room for choice in the
matter. But having handled that problem that is no longer a problem.
Repeated bounces now are at a guess more likely due to private
agressive DNSBL use. If an email service provider decides to list
lists.gnu.org on their block list then that will cause bounces which
will eventually cause the user to be unsubscribed. Talk to the email
service provider and tell them you want lists.gnu.org to be added to
the allow list. There is very little spam coming from lists.gnu.org
and we work agressively to counter the little spam that does squeeze
through.
Bob
