IIS queue and Mail delay issue. - ORF Forums

@Nagaraj: Is the Tarpit Delay test enabled? If yes, try disabling it in the Administration Tool (Configuration / Tests / Tests) then save the configuration and restart the ORF Service in one step by pressing Ctrl + U.

@PreferredOne: It can be anything that is holding up the email, e.g. timing out DNS queries or something entirely not ORF-related. Can you please send a few recent ORF PowerLog files to for analysis? These have .opg extension. Please also attach your plogrefs.dat file (can be found in the PowerLog directory) and configuration file (orfent.ini).

@PreferredOne: I am afraid that email did not reach us and our email response also bounced from your server (first there was a delay notice, then a bounce). Can you please contact us from an email address that is not affected by the queue issue? E.g. from a gmail.com or hotmail.com address.

Also, did you try stopping the ORF Service momentarily to see if this alleviates or eliminates the issue? There may be tons of reasons for queue issues and if we can rule out/confirm ORF, that would help a lot. When the ORF Service is down, no filtering will be performed and thus ORF will not be affecting your email flow.

@xx: The MIME type of .m4s files is "video/mp4", so enabling this on IIS might solve the problem (though I am not sure I clearly understand the question, I found this information in the following blog post: http://weblogs.asp.net/jeffwids/archive/2011/02/17/mime-type-for-mp4-files-is-video-mp4.aspx).

@PreferredOne: Thanks for the files. We came to the following conclusion: the problem is not caused by ORF but by this Proofpoint Encryption solution you use on your back-end server. I assume the following (correct me if I am wrong): you have two MXs, the first (primary one) is the IIS perimeter server with ORF installed (according to the configuration file, the Reverse DNS test is turned off), and you have a secondary MX published which is a Linux-based Virtual server solution (Proofpoint Encryption) with Sendmail running on the back-end. This latter server receives some emails directly (since you have an MX record published for it) and it also receives emails relayed through the first perimeter IIS+ORF server.

Emails from non-existent/bogus domains are sent to your recipient domain. The back-end Proofpoint Encryption server (with Sendmail) verifies the sender domain after the MAIL FROM: SMTP command. If the sender domain does not have an A or MX record, it reports a temporary delivery error (4.5.1) response back to your perimeter server. Since it is a temporary error, the perimeter IIS server puts these emails on hold and stores them in the queue as the SMTP standards require. It probably attempts to deliver them later again, and it receives yet another temporary error, which causes the emails to pile up in the queue.

To solve the problem, you should either configure the back-end server to drop these and/or return an 5.x.x response (indicating a permanent delivery error) to the perimeter server, or do not verify them at all (by enabling the accept_unresolvable_domains option, see http://www.sendmail.com/sm/open_source/docs/m4/features.html), or even better: enable the Reverse DNS test of ORF on the perimeter server, so emails from these bogus domains are rejected by ORF and never make it to the back-end server.

For the latter solution I also strongly recommend dropping your secondary MX to ensure all emails are relayed through the ORF-secured perimeter server and filtered there (spammers tend to target the secondary MX if they find any: http://blog.vamsoft.com/2010/02/03/drop-your-secondary-mx/).