Page MenuHomePhabricator

Ban recurrent spam to Wikimedia mailing lists (January 2019)
Closed, ResolvedPublic

Description

I am a suscriber of a number of Wikimedia mailing lists, and I administer a handful of them. Over the last weeks I've seen a particular spam email being delivered to the mailing lists and not stopped by our SpamAssasin spam protection.

Given that the sender spoofs the sending address, the spam email is shown as sent by the very same list in which the message gets delivered. There's also no different address in the mail headers that could be used.

The spammer however always use the same email subject: Directorio Empresarial Mexicano 2019 and the contents of the email are also always the same.

I am proposing at https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/488022/ a global ban for this subject, but maybe @Dzahn or @herron could come with a better solution.

Given that this spamming is targetting several Wikimedia mailing lists a centralized ban instead of a per-list approach would be preferred.

Thank you.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 5 2019, 11:20 AM

Change 488022 had a related patch set uploaded (by Herron; owner: MarcoAurelio):
[operations/puppet@production] lists: reject recurrent spam based on subject as stopgap

https://gerrit.wikimedia.org/r/488022

Dzahn removed a subscriber: Dzahn.Feb 5 2019, 6:05 PM

Change 488022 merged by Herron:
[operations/puppet@production] lists: reject recurrent spam based on subject as stopgap

https://gerrit.wikimedia.org/r/488022

herron triaged this task as Normal priority.Feb 5 2019, 6:16 PM

Thanks for the patch! As mentioned in https://gerrit.wikimedia.org/r/488022 a reject rule is now in place based on this subject. But let's keep tuning this to reject based on multiple criteria and try to find a reliable long-term filter. Do you have one or more example messages with full headers that could be shared? FWIW I've seen a few instances of this on the ops list as well, but have already deleted the messages.

Quiddity added a comment.EditedFeb 5 2019, 7:37 PM

Thanks for the patch! As mentioned in https://gerrit.wikimedia.org/r/488022 a reject rule is now in place based on this subject.

Thank you!

Do you have one or more example messages with full headers that could be shared?

Examples at P8052 and P8053 and P8054

Thanks for the emails @Quiddity and for the tweaks/merging @herron.

Ideally I'd say to force this kind of emails to be tagged as spam by SpamAssasin. Yet some emails are just tagged with X-Spam-Score: 1.2 (+) < 4 (or 6?) which is the rule we use for automatically hold a message as spam (at least that's the rule I use on the list I administer). I guess this is because of the "sender" uses the adresee as spoofed address.

Other than the subject being [$listname] Directorio Empresarial Mexicano 2019, the contents of the email are also always the same, as well as the sender name, BSM.

herron edited projects, added User-herron; removed Patch-For-Review.Feb 5 2019, 9:04 PM
herron moved this task from Backlog to Shell/site on the Wikimedia-Mailing-lists board.
herron moved this task from Backlog to Working on on the User-herron board.
herron added a comment.Feb 6 2019, 3:16 AM

Sadly I'm seeing unexpected backscatter since merging https://gerrit.wikimedia.org/r/488022. Going to revert this for now while looking closer at the cause.

Change 488226 had a related patch set uploaded (by Herron; owner: Herron):
[operations/puppet@production] Revert "lists: reject recurrent spam based on subject as stopgap"

https://gerrit.wikimedia.org/r/488226

Change 488226 merged by Herron:
[operations/puppet@production] Revert "lists: reject recurrent spam based on subject as stopgap"

https://gerrit.wikimedia.org/r/488226

MarcoAurelio added a comment.EditedFeb 6 2019, 10:25 AM

Hi @herron - I am sorry to learn it was causing problems. It did worked in preventing spam sent to meta-oversight yesterday though, and P8056 contains full message details and headers. Hope that those could provide more info to do a more accurate block.

For example: Received: from mail.isentia.asia or require an exact subject match?

This may be related- there is ongoing spam to mailing lists coming from spoofs of existing central adresses-- this can be seen by the "held messages" received at wikimedia mails ops can receive, but that obviously we didn't send.

Change 488602 had a related patch set uploaded (by Herron; owner: Herron):
[operations/puppet@production] lists:warn if unknown host issues mail from cmd containing our domain

https://gerrit.wikimedia.org/r/488602

herron added a comment.EditedFeb 6 2019, 11:03 PM

Progress! (I hope...) https://gerrit.wikimedia.org/r/488602 adds an acl to detect unknown/untrusted hosts who are attempting to issue a mail from command that contains our domain (lists.wikimedia.org in this case). I enabled this briefly in a warn-only mode on lists and it indeed flagged the same IP address from the pastes. From the lists exim log:

2019-02-06 22:42:58 H=mail.isentia.asia [203.223.144.88]:32860 I=[208.80.154.21]:25 Warning: MAIL FROM FAILURE ref1 (Remote said: MAIL FROM: incubator-owner@lists.wikimedia.org - Problem: envelope from addresses containing domains listed in local_domains are only allowed from hosts listed in the wikimedia_nets or relay_from_hosts exim hostslists)

Again the above is a warning only, no action was taken at this time. And the patch above is to persist this in warn-only mode as well. My main concern with this is false positives, so my suggested approach is to first gather data in the form of logged warnings. Then, after some time has passed, review the exim logs for false positives and finally switch to a drop action.

Change 488602 merged by Herron:
[operations/puppet@production] lists:warn if unknown host issues mail from cmd containing our domain

https://gerrit.wikimedia.org/r/488602

Change 490200 had a related patch set uploaded (by Herron; owner: Herron):
[operations/puppet@production] lists:drop if unknown host issues mail from cmd containing our domain

https://gerrit.wikimedia.org/r/490200

Change 490200 merged by Herron:
[operations/puppet@production] lists:drop if unknown host issues mail from cmd containing our domain

https://gerrit.wikimedia.org/r/490200

Change 490416 had a related patch set uploaded (by Herron; owner: Herron):
[operations/puppet@production] lists: enforce domain or ip literal HELO check

https://gerrit.wikimedia.org/r/490416

Change 490417 had a related patch set uploaded (by Herron; owner: Herron):
[operations/puppet@production] lists: drop connection if remote tries to send HELO <local domain>

https://gerrit.wikimedia.org/r/490417

Change 490481 had a related patch set uploaded (by Herron; owner: Herron):
[operations/puppet@production] lists: add 5 second smtp banner delay

https://gerrit.wikimedia.org/r/490481

Change 490481 merged by Herron:
[operations/puppet@production] lists: add 5 second smtp banner delay

https://gerrit.wikimedia.org/r/490481

Change 490642 had a related patch set uploaded (by Herron; owner: Herron):
[operations/puppet@production] lists: add 's' to smtp banner delay setting

https://gerrit.wikimedia.org/r/490642

Change 490642 merged by Herron:
[operations/puppet@production] lists: add 's' to smtp banner delay setting

https://gerrit.wikimedia.org/r/490642

Change 490416 merged by Herron:
[operations/puppet@production] lists: enforce domain or ip literal HELO check

https://gerrit.wikimedia.org/r/490416

Hi @MarcoAurelio, has this situation improved for you with the above patches merged?

Hello @herron - Since the merge of the patch that got to be reverted (Feb 5/6) I've not received any spam email of the type reported. Not sure if other mailing lists were affected though.

All seems clear on the lists I subscribe to and admin. Thanks for the work here!

lgtm too; could probably be resolved? (And big thanks!)

herron closed this task as Resolved.Feb 19 2019, 3:44 PM
herron claimed this task.

Great! Glad to hear it. Resolving

Change 490417 merged by Herron:
[operations/puppet@production] lists: drop connection if remote tries to send HELO <local domain>

https://gerrit.wikimedia.org/r/490417