How to determine if Ironport is blocking a domain

[lstreeter]

                   So our company is new to IronPort.  I am trying to determine if IronPort is blocking a particular domain.  I have tried using the message tracking option in IronPort but it returns zero results.  Our company is able to send emails to the other company's but we are not receiving emails or replies from them.  Any suggestions?

[Vance Krier]

I generally use message tracking as well.  If nothing shows up when searching by domain, try checking their MX records and search by IP on any of the IPs listed (generally speaking, most companies use the same servers for sending and receiving).  You can search the blocked connections as well.  If nothing there, verify with the company what IP they are sending from.

It is also helpful to check the reputation of their IPs using senderbase.org website to see if they are listed as negative.  Failing that, you'll have to work with the other company's IT to check their logs and/or do a cooperative test.  In that instance, its helpful to tail the maillog from the cli and watch for the connections in realtime.

Good luck!

Vance

[exMSW4319]

I have to disagree with Vance. A lot of my connection issues come from organisations that don't send through their incoming servers identified by their MX records. When I do hunt the problem down, it often transpires that the connection is from some {profane} dynamic address that should be blocked.

From memory there's a video on this forum on how to analyse your connection logs; you might want to watch it. However, the grep available on the CLI is a bit limited and I prefer to FTP my logs off for analysis elsewhere.

I would start by getting the exact error message from the sender, along with the date and time of the last attempt to mail your organisation. Armed with the time, you have a much better chance of tracking down the dropped connection. Here's an example from one of appliances; with an SBRS that low I'd guess it's a compromised PC:

Tue Feb 12 18:22:45 2013 Info: New SMTP ICID 5182346 interface Data1 address 80.238.8.128 reverse dns host ip-80-238-8-128.bskyb.com verified yes

Tue Feb 12 18:22:45 2013 Info: ICID 5182346 REJECT SG BLACKLIST match sbrs[-10.0:-1.8] SBRS -10.0

Tue Feb 12 18:22:45 2013 Info: ICID 5182346 close Tue Feb 12 18:22:45 2013 Info: New SMTP ICID 5182346 interface Data1 address 80.238.8.128 reverse dns host ip-80-238-8-128.bskyb.com verified yes
Tue Feb 12 18:22:45 2013 Info: ICID 5182346 REJECT SG BLACKLIST match sbrs[-10.0:-1.8] SBRS -10.0
Tue Feb 12 18:22:45 2013 Info: ICID 5182346 close

[Alcides Miguel]

Hi,

What command did you run to get these logs?

Best regards

[exMSW4319]

As I mentioned, the logs are drawn from the individual appliance by FTP. I do a lot of my analysis on our old Unix boxes, but the same principles can be used using any Linux distro:

ftp appliance_IP

give Administrator-level username and password

cd mail_logs

mget mail.*

bye

This presumes that your FTP client starts in binary mode, and that prompting is on or that you want to hoover up all of your logs. From memory the mail.current is simply a duplicate of the latest dated log file and can be subsequently removed.

I then use grep to narrow down what I'm after. There's an implementation of grep in the Asyncos CLI itself but I frequently pipeline greps together, redirect output to temporary files and even construct short loops. These are all techniques that would depend on the shell you're using.

From my example of a few years ago:

grep "Tue Feb 12 18:22" mail.current | grep "REJECT" > r1

Which can be loosely translated as "take all of the log entries for 18:22 12/2 and put the rejections in temporary file r1".

From there it's possible to use the same searching method to see what happened for each of those ICIDs. It's not a perfect solution, as the appliance (rightly) drops the connection as soon as it thinks the sender is bad and before it has obtained recipient or subject information. However, if you know when your problematic sender was rejected you can generally work out which rejection is the problem. If the sending network isn't a problem for me, I never hesitate to put a dedicated MTA in my whitelist and take a view on any shared equipment. Any lame, nameless or genuinely problematic equipment should be pointed out to your recipient as the cause of the non-delivery. Remember to stress that it's probably the sending network rather than the sender that's at fault, as people can take this sort of thing very personally.