openstack email server blacklisted

[Father Vlasie]

ask.openstack.org email server blacklisted again!

IP address: 23.253.72.95

From address: <email address hidden>

Reputation Mailspike DNSBL - see http://mailspike.org/iplookup.html

[Stefano Maffulli (smaffulli)]

Delivering email reliably is too hard to do from ask.openstack.org. The best solution at this point is to hook-up the service to a reliable SMTP server, like the same used by lists.openstack.org. I don't know how/if this can be done.

Assigning this to the core infrastructure team, hoping they have ideas.

[Clark Boylan (cboylan)]

lists.openstack.org is its own mail server. It doesn't use any other service.

In this case is the issue that ask.openstack.org is sending mail for openstack.org? I don't think it should be doing that.

[Jeremy Stanley (fungi)]

Strange that the mailspike lookup form claims "worst possible reputation" when Talos (formerly Senderbase) isn't indicating presence on any widely-used blacklists: https://talosintelligence.com/reputation_center/lookup?search=ask.openstack.org

The current SPF record for openstack.org is "v=spf1 include:sendgrid.net a:review.openstack.org a:mail.zendesk.com include:emailsrvr.com include:e2ma.net ?all" so unless we're going to set the sender to something @ask.openstack.org we should probably add a:ask.openstack.org in there. That said, I can't imagine a blacklist adding hosts solely for sending messages with an address which isn't included in a ?all SPF record. I'll see if I can spot any nefarious use from the MTA logs.

[Jeremy Stanley (fungi)]

Messages logged by the MTA look like relatively typical patterns for the notification mechanisms askbot provides. Some of the rejections logged also mentioned the IPv4 address showing up on the Spamhaus PBL (which is not uncommon for Rackspace servers so we tend to file exceptions for them if we know they'll be sending E-mail), but Spamhaus's lookup form does not indicate this is actually the case either.

I also ran a packet capture on the server looking at all SMTP traffic, and didn't see any being sent outside the MTA (e.g., via direct socket connections).

[Jeremy Stanley (fungi)]

I've requested delisting from the Mailspike BL for now.

[Jeremy Stanley (fungi)]

The server is no longer showing up in the Mailspike BL, but I'll keep an eye on that over the next few days. I'm also no longer seeing nearly as many vague rejections from random MTAs in the log (though qq.com seems to fairly consistently reject with a "mail content denied" message.

[Jeremy Stanley (fungi)]

The server remains on (or perhaps continues to get relisted on though I see no indication their delisting interface actually does anything) the Mailspike RBL after repeated delisting attempts. Given that the blacklists tracked at https://talosintelligence.com/reputation_center/lookup?search=ask.openstack.org as well as the ones tracked by http://multirbl.valli.org/lookup/23.253.72.95.html (except for Mailspike on the latter) indicate no problem, and seeing no way to easily find out why we seem to keep running afoul of Mailspike, I'm going to mark this bug report as won't fix for now. It's unfortunate, but it looks to me like Mailspike is probably an overzealous and/or unreliable blacklist (which may be part of the reason Talos doesn't acknowledge their listings).

[Jeremy Stanley (fungi)]

As a last followup (for now), I did eventually manage to get the server delisted in Mailspike and set up a packet capture to log all E-mail exiting the server. With a few days it ended up listed in Mailspike again with "worst possible reputation" and the only messages which ever left the server were notifications about updated questions going out to people who had explicitly subscribed to the tags associated with those questions. I have to assume that someone has somehow managed to subscribed a Mailspike honeypot address or is reporting the notifications to Mailspike as spam, but either way I don't see any solution to this short of disabling E-mail notification for the server or clearing everyone's subscription preferences and asking them to re-subscribe to question tags all over again.