3

We use Office 365 as our primary mail provider. We have an internal mail server that we use for relaying things like reports from our SSRS, scan to inbox for old scanners, etc. It is an IIS SMTP on server 2008R2. This server is not exposed through the firewall for any service, and certainly not SMTP, and is connection restricted and relay restricted to the few internal IP addresses on our network that use it as a relay. We use this because not every device we use is capable of using the office 365 services directly (we are a nonprofit and some of our older devices are indeed quite older), along with process control equipment in our manufacturing, things that just do not allow for authenticated/TLS SMTP, to make a short story long, there are several essential conveniences that this system provides to the local network, and there should be no reason we should not be able to use the conveniences. We took all of our precautions, we have proper DNS entries for the server. I have SPF records set for its IP, the name the server advertises when it delivers resolves to its public IP. Everything has worked great for over 1.5 years (since migrating to office 365) in this configuration without issues.

Suddenly one day all mail coming form it started getting rejected, by proxy of being listed in spamhaus and CBL.abuseat, spamhaus states that they are listing by proxy of the CBL entry, CBL states we were listed for sending “staggering large volumes of spam”, they cite that server’s DNS name as being the source. Unless it is using telepathy protocols, we average about 60, and have never sent more than 100 emails in a day, and I have now over three month of captured traffic that show not a SINGLE message that did not originate from a known source, and was not destined for an address that we commonly send to (99% of which are all internal addresses anyway!) So aside from the diatribe that the “help page” spews about all the potential causes for this, how we likely been compromised, how to scan for infections in services we do not even run, etc…. We have without question verified that the claim is false, we have monitored all network traffic to and from that machine from a mirrored switch port using Wireshark, we have monitored all traffic at our border firewall, we have had our ISP confirm the same from their side, we simply are NOT sending any mail we have not explicitly wished to send. From that machine or this IP address. Yet this if now the 4th removal request I have had to process with them. I managed to get two emails from their system, as I was requesting samples of the mail that they claim to be transmitted by us, one is a verbatim copy of their “Help Page” and a request for the IP in question, the other is some chipper reply that is worded like a robot, signed “Murray”, and of no help whatsoever. It seemed that one was a canned reply to the first’s IP request stating it had been submitted for removal already.

We contacted Microsoft to find out that their connection filtering occurs prior to our admin control, meaning setting an “approved sender” is useless if the IP reputation filters disconnect us before it gets to that level. So we cannot whitelist ourselves around this. And they claim zero responsibility for using the service, or the fact that it controls mail flow between our paid service and our business network in a manner neither of us can modify. The only thing we can even conceive is that maybe one of the scan to inbox messages is being forwarded to some overzealous spam filter somewhere, and we are being flagged as being a transport method in the chain of. So I am stuck with nothing to go on, I cannot get movement out of abuseat, I cannot get Microsoft to budge, I have proof that we are being falsely listed, and no evidence to the contrary to even begin to look further into, at a complete loss for what to do other than start changing my public IP and all services dependent on it. I have dealt with open relay securing in the past, and cleaning up the fallout thereof, but this one is absolutely confirmed bogus, and no one to take it up with. But they have us by the short hairs.

Sabre
  • 283
  • 1
  • 10
  • 1
    After reading all that wall of text, I don't really see a *question* here. – ceejayoz Jan 21 '17 at 00:47
  • To be clear is it your servers IP listed by Spamhaus or is it the O365 relay? – Tim Brigham Jan 21 '17 at 14:15
  • 1
    Sorry I had a dozen things going at once, the question is, how can one possibly combat this, there is no other way to chase through cbl.abuseat.net, they will not provide evidence, and their listing is confirmed false, yet it keeps occurring. How does one fight this short of an attorney. Spamhaus is listing us because CBL is, and MS is disallowing connections to deliver mail from our office IP because it is hitting their "ip reputation filter" prior to the white list. – Sabre Jan 22 '17 at 17:51

0 Answers0