Adding operations

I think @MarkTraceur was seeing something similar?

I've been seeing these reports on multimedia-team and multimedia-alerts. None of the postmaster addresses work, and none of the phone number addresses work, either. I can't seem to find any setting to disable these notices, nor to block this e-mail address, in mailman.

"If bounce_unrecognized_goes_to_list_owner is Yes, any message received at
the listname-bounces address which is not recognized by Mailman as a
DSN is forwarded to the list owner as an unrecognized bounce since at
that point, Mailman doesn't know if it was an actual undeliverable
mail DSN or something else."

https://mail.python.org/pipermail/mailman-users/2007-December/059531.html

see these settings:

Should Mailman perform automatic bounce processing?

Should Mailman send you, the list owner, any bounce messages that failed to be detected by the bounce processor? Yes is recommended.

and the general text above the other bounce settings

These are per-list settings.

quote from mailman UI:

//While Mailman's bounce detector is fairly robust, it's impossible to detect every bounce format in the world. You should keep this variable set to Yes for two reasons: 1) If this really is a permanent bounce from one of your members, you should probably manually remove them from your list, and 2) you might want to send the message on to the Mailman developers so that this new format can be added to its known set.

If you really can't be bothered, then set this variable to No and all non-detected bounces will be discarded without further processing. //

Thank you Dzahn,

So I should convey the following information to Samir?

Should Mailman perform automatic bounce processing? <
https://lists.wikimedia.org/mailman/admin/education-collab/?VARHELP=bounce/bounce_processing

Should Mailman send you, the list owner, any bounce messages that failed to
be detected by the bounce processor? Yes is recommended. <
https://lists.wikimedia.org/mailman/admin/education-collab/?VARHELP=bounce/bounce_unrecognized_goes_to_list_owner

and the general text above the other bounce settings <
https://lists.wikimedia.org/mailman/admin/education-collab/bounce>

These are per-list settings.

quote from mailman UI:

//While Mailman's bounce detector is fairly robust, it's impossible to
detect every bounce format in the world. You should keep this variable set
to Yes for two reasons: 1) If this really is a permanent bounce from one of
your members, you should probably manually remove them from your list, and

2. you might want to send the message on to the Mailman developers so that

this new format can be added to its known set.

If you really can't be bothered, then set this variable to No and all
non-detected bounces will be discarded without further processing. //

The same thing is happening on the social-media, research-newsletter and wikimediaannounce-l lists.

Hello All,

Not sure if I should send another Phabrictor ticket, but we just received
this ticket from Nick:

Hi! I'm getting a number of these messages (18 over the last 24 hours

• http://i.imgur.com/TEoCzvD.png )

sent to ee-owner@ and design-owner@ (2 of the lists I administer).
I've searched the list of subscribers, but there aren't any that use
an att.net address (I just ctrl-F searched for "att", on each of the
alphabetical pages of members).
Any idea what I should do, next?
Thanks!
Nick / Quiddity

Seems like the same situation.
Please advise.

Thank you,
Eliza

We're having this same problem on the Cascadia mailing list.

Same for mediawiki-commits.

Same for checkuser-l, overight-wp-simple-l, cvn-l, publicpolicy and probably any other list I administer (I already deleted most mails)

Okay, I think it's clear now that this is happening on plenty of lists. :)

Also Wikidata.

Also fundraiser

AND MY AXE!

Wait, I mean, and my mailing lists. The Discovery Department's mailing lists are affected by this too.

Thank you everyone !

I saw 12 of them in 24 hours for one of the lists I administer. All of them for the same number as in the above report, but note it was @mms.att.net, not txt.att.net (I have seen that in the past, though, it's something that happens from time to time). Each subscription request came from a different IP address, mostly Chinese (9) but also from Poland, Colombia and Brazil.

I don't really know what's the point in doing this (flood someone's phone?) Is there any reasonable need of receiving a mailing list at txt/mms.att.net? (would someone want to do that?) Otherwise, banning the domain for subscribing would be appropriate.

Just so I don't feel left out, Wikipedia Library list is getting one every few hours.

In T112912#1651887, @Platonides wrote:

I don't really know what's the point in doing this (flood someone's phone?) Is there any reasonable need of receiving a mailing list at txt/mms.att.net? (would someone want to do that?) Otherwise, banning the domain for subscribing would be appropriate.

Honestly I'd be supportive of just banning the domain from a root level, especially if it can stop email to -owner too because the domain is one of the more common ones I've seen for spam emails in general. So far up to 50 of these bounce notifications ;)

This has happened before, to varying extents. It strikes me that someone has found a way to spoof the WMF mailing list addresses, and the ATT group is sending bounces. We get a lot of bounces like this for the (very longstanding) checkuser list - not just from ATT - a few a week, at least.

Same for wikimedia-ped

Thanks to all who are working to solve this! :-)

In T112912#1652035, @Ocaasi wrote:

Just so I don't feel left out, Wikipedia Library list is getting one every few hours.

I'm up to 30 of these "Uncaught bounce notification" e-mails. :-)

Has someone tried just calling the number and explaining the situation? (It seems to be a real US phone number with a North Carolina area code, with reverse search resolving to a real-sounding name, "R.B.". See also https://www.att.com/esupport/article.jsp?sid=KB92125&cv=820 )

If Platonides' hunch is right and this is a failed attempt to harass this person (failed because, see above, "the subscriber has restricted e-mail" to their number), they might be interested in the originating IPs. (Which BTW, @eliza, one might generally want to redact for privacy reasons before posting something like this on a public bug tracker - but in this case there's probably not much harm done, as that Thai IP appears to be one of many proxys used by an attacker.)

In T112912#1650147, @eliza wrote:

So I should convey the following information to Samir?

@eliza Yes, please forward my original comment along with this:

This message is also for all other affected list admins:

You can go to the following URL, where you have to replace <LISTNAME> with the name of your list:

https://lists.wikimedia.org/mailman/admin/<LISTNAME>/?VARHELP=bounce/bounce_unrecognized_goes_to_list_owner

login with your admin password., and switch from Yes to No

"Should Mailman send you, the list owner, any bounce messages that failed to be detected by the bounce processor? Yes is recommended."

Then hit "Submit your changes", and let me know if it helped.

Also see the comments above though why mailman says this is not a good permanent solution to just ignore all of them. Legitimate bounces should still be checked and unsubscribed where needed.

This is getting annoying. Can someone just patch this up to get rid of this junk?

@Multichill Did you try what i suggested in my comment right above?

In T112912#1653157, @Dzahn wrote:

@Multichill Did you try what i suggested in my comment right above?

I'm admin for quite a few lists. And as pointed out this is not advised in the manual. This is a server wide problem and should be solved server wide, not on a per lists basis.

First comment for the sake of everyone: please can people stop commenting things that add no value or enhance the ability for us to look into the issue. the 'xx list also' comments are useless and just ironically generate more emails for people.

Now my comment: I'm assigning this to myself and I will look at it in detail when I can. This is extremely low priority right now considering the mailman migration and that follow up (security over mindless issues). This *will* be addressed through the correct channels. Per-list things are the only thing that can be done as mailman has no concept of global list configuration. since these are bounces by mailman, there is nothing we can do to solve that issue besides fixing *this* issue.

I hope everyone respects that our focus right now is elsewhere within mailman and that more comments don't really make things move faster (in fact we're discussing this so much, the migration is become more and more likely to take longer).

Thanks!

Hi John,

In T112912#1653302, @JohnLewis wrote:

First comment for the sake of everyone: please can people stop commenting things that add no value or enhance the ability for us to look into the issue. the 'xx list also' comments are useless and just ironically generate more emails for people.
Now my comment: I'm assigning this to myself and I will look at it in detail when I can.

Last time I checked you were not on the operations team or do you have shell access to the machine?

This is extremely low priority right now considering the mailman migration and that follow up (security over mindless issues). This *will* be addressed through the correct channels. Per-list things are the only thing that can be done as mailman has no concept of global list configuration. since these are bounces by mailman, there is nothing we can do to solve that issue besides fixing *this* issue.

You're looking the wrong place. The mailman server runs Exim. In Exim you can just setup a blackhole route send this junk to /dev/null .

I hope everyone respects that our focus right now is elsewhere within mailman and that more comments don't really make things move faster (in fact we're discussing this so much, the migration is become more and more likely to take longer).

No, I don't agree with that. This is a classic IT problem: The current product is not done or malfunctioning and the new product isn't ready yet. I'd suggest you have an operation engineer with exim experience set the null route so this ticket can be closed and you have your hands free for the migration. I'm sure ops is more than willing to help out here.

In T112912#1653355, @Multichill wrote:

Hi John,

In T112912#1653302, @JohnLewis wrote:

First comment for the sake of everyone: please can people stop commenting things that add no value or enhance the ability for us to look into the issue. the 'xx list also' comments are useless and just ironically generate more emails for people.
Now my comment: I'm assigning this to myself and I will look at it in detail when I can.

Last time I checked you were not on the operations team or do you have shell access to the machine?

Yes. I have sudo access to the mailman server.

This is extremely low priority right now considering the mailman migration and that follow up (security over mindless issues). This *will* be addressed through the correct channels. Per-list things are the only thing that can be done as mailman has no concept of global list configuration. since these are bounces by mailman, there is nothing we can do to solve that issue besides fixing *this* issue.

You're looking the wrong place. The mailman server runs Exim. In Exim you can just setup a blackhole route send this junk to /dev/null .

What junk? Bounces are important to list administrators and also site administrators to help debug issues.

I hope everyone respects that our focus right now is elsewhere within mailman and that more comments don't really make things move faster (in fact we're discussing this so much, the migration is become more and more likely to take longer).

No, I don't agree with that. This is a classic IT problem: The current product is not done or malfunctioning and the new product isn't ready yet. I'd suggest you have an operation engineer with exim experience set the null route so this ticket can be closed and you have your hands free for the migration. I'm sure ops is more than willing to help out here.

Just to put it into perspective - the migration is *right now*. Likely to finish in less than hour.

In T112912#1653382, @JohnLewis wrote:

This is extremely low priority right now considering the mailman migration and that follow up (security over mindless issues). This *will* be addressed through the correct channels. Per-list things are the only thing that can be done as mailman has no concept of global list configuration. since these are bounces by mailman, there is nothing we can do to solve that issue besides fixing *this* issue.

You're looking the wrong place. The mailman server runs Exim. In Exim you can just setup a blackhole route send this junk to /dev/null .

What junk? Bounces are important to list administrators and also site administrators to help debug issues.

Obviously this att junk which is hitting our inbox. This bounce is not important, just annoying.

I'm going to agree with John here that bounces are important. They are flags that there is a problem with the process - the level of importance of the problem will vary. That lots of lists are getting the same flag repeatedly is actually quite useful information that helps to define and prioritize this issue.

I also agree that this issue should take lower priority than the conversion that had already been scheduled and is in the middle of implementation. Once the conversion is complete, I think it would be reasonable to expect that its priority will be escalated.

Thank you for taking care of it, Eliza and John!

Should Mailman send you, the list owner, any bounce messages that failed to be detected by the bounce processor? Yes is recommended.

@JohnLewis do you recommend changing it to "No" temporarily until the issue is solved?

You can probably just add 2524063603@mms.att.net to https://lists.wikimedia.org/mailman/admin/<listname>/?VARHELP=privacy/subscribing/ban_list if you are concerned about unsubscribing from bounces altogether. That said, the reason given in the mailman manual to not disable bounce reporting is that you can report suspicious bounces to the mailman developers if you see them. If you don't really see yourself doing that (especially for a mailman release that's fifteen months old), you shouldn't worry about disabling it IMO.

In T112912#1654211, @Selsharbaty-WMF wrote:

Should Mailman send you, the list owner, any bounce messages that failed to be detected by the bounce processor? Yes is recommended.

@JohnLewis do you recommend changing it to "No" temporarily until the issue is solved?

Yes, just do that if it bothers you, as already suggested twice in this thread.