JIRA email - IP Found in RBL

[Kelvin Yap]

Mimecast is blocked some emails from JIRA:

Type10020

DescriptionIP Found in RBL

Informationspamcop.mimecast.org Blocked - see https://www.spamcop.net/bl.shtml?192.174.81.121

Anyone else having the same issue?

[Andy Heinzer]

Hi,

I found that this IP address in the past has been identified within certain mail block list services.  However at this time it appears to have been removed from that list.  

This IP is potentially in the range of addresses we designated in IP addresses and domains for Atlassian cloud products for outbound email from our Cloud services.  Sorry for the inconvenience this might have caused.  In the future, should you find this problem with another Atlassian address, I'd recommend creating a support case over in https://support.atlassian.com/contact/

If you're not a site-admin, or your a user of a free plan site only, then that contact form will redirect you to Community per our Support Offerings.  You are still welcome to report these to Community as well, however our response time will certainly be slower here.

[Nic Brough -Adaptavist-]

Nope, spamcop is listing your email server, not an Atlassian one.  You'll need to talk to spamcop about getting your email server off their spam list.

[ben.terbrake]

This is absolutely incorrect - the IP 192.174.81.121 is owned and used by Sparkpost, which it seems that some Atlassian email routes through - the SPF record for my business' instance includes %{i}._spf.sparkpostmail.com.

I'm having this issue now too. I'll be reaching out to our support to get them to follow up with challenging the spamcop blacklist.

[Nic Brough -Adaptavist-]

Nope, you don't understand how it's working.  But reaching out to your support is the right thing to do.

[ben.terbrake]

Would you mind explaining for anyone else who comes across this issue?

We have a Cloud instance that is in no way linked to any of our own on-prem servers. We suddenly started having emails being blocked or rejected by both our own filtering (Mimecast) and that of our customers.

The rejection messages are exactly as above - pointing to a spamcop block of 192.174.81.121.

This IP is not that of my email server (which isn't linked to our Atlassian instance anyway). I can almost guarantee it's not that of the OP's either. We don't use Sparkpost for any of our services - but Atlassian does.

In what way am I misunderstanding? And if I am, why then would reaching out to my support still be the solution?

As an update on the issue, the spamcop blacklist entry expired automatically and was removed.

[Nic Brough -Adaptavist-]

Mimecast/spamcop are blocking stuff from an email server/relay (which is not owned or deliberately used by any particular source of email)

So, if you want to get email that is coming from there, you need to ask Mimecast/spamcop to allow it through, or stop using them.

[Yatish Madhav]

Thank you for the responses here. Please advise what the best course of action is for this? I.e if the email is coming from a valid IP that Atlassian has documented but is on abuseIP?

[Yatish Madhav]

Hi - is there any update on this for us? Thank you

[ben.terbrake]

Hi Yatish - my last reply to Nic explaining further why he is wrong has been removed, it seems, which is frustrating as this means this entire thread is a red herring for people.

Aside from whitelisting the IP on your side, and asking ALL your customers/external contacts to whitelist the IP on their side, there's nothing you can do but wait for the blacklisted IP to expire (in the case of spamcop, anyone - not sure about abuseIP)

Exactly as you said, Atlassian have these IPs documented as a source of their emails (under 'Outbound email' here: https://support.atlassian.com/organization-administration/docs/ip-addresses-and-domains-for-atlassian-cloud-products)

When they are blacklisted, they don't have any method of removing the blacklist or re-routing email to use other servers/services.

Raise a support ticket, but I doubt they'll do much. There's an open 'suggestion' here that has got zero traction: https://jira.atlassian.com/browse/JRACLOUD-77758

[Nic Brough -Adaptavist-]

I suspect your reply was moderated away because it was giving incorrect information - red-herrings exactly as you say.

It is not up to Atlassian to get something off a blacklist, you need to talk to the people who have blacklisted it.   You have chosen to use their blacklists, not Atlassian.

[ben.terbrake]

I doubt it, as nothing I've said was incorrect - you still don't seem to get it.

Atlassian are the one using these IP addresses. Again, see the 'Outbound email' section in https://support.atlassian.com/organization-administration/docs/ip-addresses-and-domains-for-atlassian-cloud-products/

In that list is the network 192.174.80.0/20. Included in that range is the IP 192.174.81.121 from my original comment.

This is Atlassian's own documentation stating that they send email via this IP.

When it is flagged by one of the various security services like spamcop or abuseIPDB, there is nothing I can do. I have not chosen to use this IP or this service - Atlassian has. Therefore, when it is blacklisted, it is absolutely Atlassian's responsibility to resolve.

What is incorrect about anything I have said here?

[Nic Brough -Adaptavist-]

Don't seem to get what?

What I have is:

Atlassian have an IP address that some security service have black-listed.

You have chosen to use that security service to scan your email (whether directly, or by using an email provider who uses them)

Most importantly, Atlassian are not using this security service to check their outgoing email, that's not what it is for.  (This is the part of your statement that might have caused your last post to be removed - it's wrong).

[ben.terbrake]

Ah, I see why you're confused.

Incidentally, this is a big change away from your original statement of 'Nope, spamcop is listing your email server, not an Atlassian one.'

We've progressed and are now in agreement that the IP 192.174.81.121 (for example) is used by Atlassian. And you're correct in saying that Atlassian themselves aren't using spamcop, AbuseIPDB, etc. (I've never stated that they use them either.)

What I think you don't realise or grasp the importance of is how widely used these security services are. An enormous number of organisations will use tools like Mimecast or Symantec to manage their incoming emails, and these services make use of blacklists provided by spamcop etc. When an IP used by Atlassian is blacklisted, a large number of emails are then not delivered to where they need to be.

My own systems are not an issue - I can whitelist on my side - but we have hundreds of customers who also use Mimecast/Symantec/Barrcuda/Proofpoint, for instance. When an IP is blacklisted, emails from my Atlassian environment to them will be blocked or marked as spam.

We pay for Atlassian. Even though they have no relationship with these blacklists or these third-party email services, it's not acceptable for them to just say 'not our problem' - it's a service that is not doing what it should because they are using an IP that is being added to extremely commonly used blacklists.

If emails from Atlassian IPs to Office 365 or Google Apps were to all be marked as spam, would it be reasonable to say "well, guess you shouldn't use 365 - nothing to do with Atlassian"? This is a slight exaggeration, but it's the same scenario.

[Nic Brough -Adaptavist-]

Again, you've missed the point.

Atlassian are not using those blacklists.  There's nothing they can do about your use of email blacklists.

[ben.terbrake]

Hi Nic - again, we're in agreement that Atlassian don't use these services themselves.

However, people need to understand that in these scenarios it is an Atlassian IP that is being blacklisted by commonly used third-party security services, which means that end users are not able to do anything. Either the blacklist will expire itself, or Atlassian would need to challenge it.

I personally think that Atlassian should take better ownership of when this happens or have a method of routing emails via a different IP, but we can disagree on that.