Delayed Email Delivery

Been looking at the logs, but they have not suggested anything.  Users didn't initially communicate this, so it is hard to know when it started.  However, I do not believe that there have been any changes to our environment.  If it was our AV, I'd expect a flat quarantine/rejection.  Same with Exchange and our firewall.  Basically, it should be all or nothing.  One of our IPs was showing up on 3 Blacklists for a period, so that could have come into play, but I'd expect that to be an all or nothing issue, too.  The fact that we're receiving the emails expected, but just delayed, is the issue.  And it is just a handful of users/domains.  I've run message header analyzers, but they have not provided any indications of the issue.  They basically just show a long delay for the last hop (external email server -> our internal email server IP).  We don't have an SPF record, currently.  Not sure if that would come into play, as I'd again expect it to be an all or nothing situation.

Thanks,

Jeremy

I would look at the email's headers to find if the emails that get delayed take a similar path.
Sounds like some remote servers have issues sending the email the first time.
This could be due to grey listing or other mechanisms to block spoofers on your antispam solutions.

if this is the case, most likely these senders do not have proper SPF records or similar, triggering your antispam solution to not accept the email first time.


View example configurations and the SonicWALL webui and features on http://livedemo.sonicwall.com or http://ngfw-demo.com

Multiply the effectiveness of your APT Sandbox, stop unknown and zero-day attacks at the gateway. See a demo on http://apt-demo.com or http://atp.demo.com

You can also view the Next-Generation Firewalls via
http://next-generation-firewall.com or http://next-generation-firewall-demo.com

Also make sure your own SPF records are setup properly.
How did you get blacklisted?
It's easy to get on, but hard to get off, and yes that has tons of impact in receiving emails...

If you have multiple public IP addresses, it's best to One-to-One NAT your exchange inbound and outbound to a unique IP address, make sure this matches your SPF records and vice versa.

We got on a blacklist due to one of our users' profile was compromised by the Gozi Trojan.  Once I got that cleaned up, I monitored for 10 days and then de-listed us.  We have been fine since.  We do have unique IPs for outgoing and incoming IPs, so damage was minimal.  The issue was that the attack doesn't use port 25, so it was going out our firewall's IP.  Anyhow, I do plan to make an SPF, but as I haven't done it before and have to take into consideration our secure email product (Zix Corp), I've been just collected info on it.  These email issues are escalating it, though.  I'll look through the links and see what applies.  My general position has been that its the sender and not us, but I do want to make sure that I'm not sitting on a misconfiguration.

Here's a good tool http://www.spfwizard.net/ to create the spf record.

What normally happens during an email communication, e.g. I send an email from mydomain.com to your domain.com

my email server will do an MX lookup for yourdomain.com than establish a direct SMTP connection.
if this fails, my server qill put it in the queue and will retry later.

What is your MX record pointing to?
If it's poiting to your own network directly, it sounds like the remote servers are not able to deliver the email at first touch.

From the email header, you can see which paths it took. See if there's a pattern in there and if there's an inbetween MTA agent which is causing the grief.

Not abandoned.  People go on PTO and work on other items.  That said, I've checked through all of our AV, firewall, and Exchange products/services.  There is absolutely nothing that would hold an email for 1-6 hours.  Everything is either allowed after initial inspection or rejected after initial inspection.  Out of a handful of impacted senders, I'm seeing that half are using Google servers, so there is something there.  I'm implementing an SPF record today.

Not really resolved, but the evidence suggests that it is out of our control.