IIS queue and Mail delay issue. - ORF Forums

IIS queue and Mail delay issue. RSS Back to forum


Hi, We are using ORF 4.2 enterprise version with IIS smtp. In the recent past facing performance issues, with mail delay and queue build up.

I have noticed the following,

1) IIS SMTP has received email and could see the inetpub\mailroot\queue folder with lots of files.
2) The iis queued mails I can see beroe arrival log entry in ORF application.
3) However the mails are not processed fast and onarrival test are pending for the IIS quedued mail.

Let me know if this is one of the know issue or any configuration changes will help in increasing performance of ORF.


by Nagaraj 9 years ago

@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.

by Krisztian Fekete 9 years ago
(in reply to this post)


We're having the same issue with this on 4.4. We've disabled tarpit delay but it will stop and fill up the queue again. The only fix for now is to do a iisreset that restarts smtpsvc. Any other things that I need to look at.

by PreferredOne 7 years ago

@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).

by Péter Karsai (Vamsoft) 7 years ago
(in reply to this post)


I've sent the logs and problem description with the same subject as the topic. Hopefully someone can help us. Thanks.

by PreferredOne 7 years ago

@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.

by Péter Karsai (Vamsoft) 7 years ago
(in reply to this post)


I have downloaded some .m4s files.I tried running them on VLC player using IIS server.But its not supporting tht format.Do i have to add any mime types and format for .m4s files on IIS server? If yes then what is the mime type and format for .m4s files?

by xx 7 years ago

@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).

by Krisztián Fekete (Vamsoft) 7 years ago
(in reply to this post)


@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/).

by Krisztián Fekete (Vamsoft) 7 years ago
(in reply to this post)

New comment

Fill in the form below to add a new comment. All fields are required. If you are a registered user on our site, please sign in first.

It will not be published.
hnp1 | hnp2