4

I have a PHP web app which is using SMTP to sendmail on localhost to send email.

I would like sendmail to accept the mail request immediately and queue it for later sending, as I don't want to have user-facing request threads blocked on emails.

Sendmail is installed with the default settings on RHEL web servers.

Sometimes sendmail is blocking for a long time after the MAIL command is sent -- sometimes taking 60 or 90 seconds to accept the mail. The time take is usually very close to 60 or 90 sec, which makes me think this is some kind of timeout.

I have looked in the sendmail logs, and there are plenty of "deferred" emails, but nothing which looks responsible for this delay.

  1. How can I diagnose what is slowing down sendmail?
  2. How can I configure sendmail to always accept the mail immediately and to queue the mail for later sending?

Update: I'm not sure, but it looks like this might be linked to aol.com addresses. I strongly suspect that sendmail is doing some kind of blocking receipient address verification at the accept-email-for-sending stage. How can I disable that, so that sendmail doesn't block my UI threads?

Update 2: This only seems to happen at busy times. Perhaps I am running out of sendmail threads or something? How can I check that?

Rich
  • 704
  • 14
  • 30
  • 3
    I'd look at DNS settings - if sendmail is e.g. trying to check whether the HELO matches the hostname of the sending server, or whether the server has correct DNS records, a DNS timeout would match the times you're seeing. – Jenny D Nov 08 '13 at 15:02
  • I looked in the sendmail config, and I couldn't see anything relevant. Please could you be more specific? What settings should I check? – Rich Nov 08 '13 at 17:16
  • 1
    1) Have you considered using sendmail progmail directly (without SMTP)? 2) Check your sendmail.cf for 30s settings. I do not remember any default sendmail setting casin n*30s delays at "MAIL FROM:" (I remember something but at SMTP connection setup stage) – AnFi Nov 09 '13 at 17:04
  • @Rich Start by checking if DNS lookups function properly from that server, e.g. by using `dig` to lookup www.google.com – Jenny D Nov 10 '13 at 11:25
  • DNS works fine. – Rich Nov 10 '13 at 22:58

2 Answers2

1

There are several sendmail tuning parameters that can affect the initial delivery attempt. Have a look at Sendmail Tuning.

rickhg12hs
  • 394
  • 2
  • 9
  • Thanks, I've had a look in there and I can't see anything that affets me. The "`DeliveryMode`" is set to "b deliver in background (asynchronously)". I still can't explain why I'm seeing long delays at the accept email for delivery stage from `sendmail` during busy times. I strongly suspect `sendmail` is doing some kind of recipient verification. Any ideas? – Rich Nov 12 '13 at 09:35
  • Puzzling. May be time to breakout [Wireshark](http://www.wireshark.org/) and find out exactly what network traffic you have at each "stage" of your mail delivery. You could also monitor the mail queue to see when files "arrive". – rickhg12hs Nov 12 '13 at 09:48
  • 1
    I don't have a reproducible test case, so I can't really sniff the traffic. I have given up on fixing sendmail, and I wrote an app-layer email queuing system that pipes emails into sendmail in a background thread, to isolate my app from these random delays. – Rich Nov 14 '13 at 14:28
0

I have been unable to fix sendmail, so I wrote an app-layer queue to hold emails before they go to sendmail, which negates this problem for me. The emails are queued on disk by the web request threads, and then a single background thread (per web server) passes the emails to sendmail from that queue.

I have added extra logging, and sendmail is still occasionally blocking when receiving emails (now only for 5-15 seconds). I had thought sendmail was designed to accept all the emails immediately, without blocking, and then attempt to deliver them to their final recipient in the background on its own queue.

The frequency of slow emails is now much lower. I wonder if part of the problem is that sendmail was running out of "receive" threads.

In my original setup, all the PHP request handling threads would pass their emails into sendmail (via SMTP) as soon as a user action caused an email to be sent. At busy times, this must have meant that sendmail was receiving lots of emails in parallel. It was occasionally blocking for 60-90 seconds (which was disastrous for my app's performance).

Now that I have added this app-layer queue, which pipes emails to sendmail on at most 1 thread, sendmail appears to be able to cope fine (most of the time) with the same volume of emails without blocking at all. It does occasionally block though, which makes it unsuitable as an email queueing layer.

Rich
  • 704
  • 14
  • 30