Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a Rails app used for support & help tickets.

It sends customers a confirmation email when they submit a request. It also sends an email when we reply to their request. It does not receive mail.

Within the last week, 25%+ of our customers stopped getting their replies. They think we aren't replying to their ticket (when we actually are).

I did a test with my account and found this in the mail.log file:

Jul  9 16:11:45 bighelp postfix/smtp[9051]: BF673324365: host[] said: 451 Message temporarily deferred - [140] (in reply to end of DATA command)
Jul  9 16:11:45 bighelp postfix/smtp[9051]: BF673324365: to=<>,[]:25, delay=0.73, delays=0.02/0.02/0.64/0.05, dsn=4.0.$

Other non-yahoo addresses are experiencing this as well.

The Rails app is running on Ubuntu and we are sending via:

ActionMailer::Base.delivery_method = :sendmail

I made sure the server isn't an open relay.

What else can I do to ensure most of our emails get through?

share|improve this question

This message is often to do with greylisting (particuarly with yahoo who seem to do it to everyone at some points). Basically the mail server temporarily defers your first mail, a legitimate email server will see this message, wait a period and then try again. Servers that are sending spam are often set to just send out bulk loads of mail and forget about, it so will never try again, and so the spam is dropped.

To ensure you can get through the greylisting ensure your mail server is set to try again after a deferral, and give it a reasonable time windows, 10-20 mins is usually enough.

share|improve this answer
Ok, thanks. I did another test with a non-Yahoo account and found this in the log: Jul 9 16:39:10 bighelp postfix/cleanup[9148]: 43CFE324361: message-id=<20090709163910.43CFE324361@bighelp> Jul 9 16:39:10 bighelp postfix/qmgr[3817]: 43CFE324361: from=<>, size=3236, nrcpt=1 (queue active) Jul 9 16:39:10 bighelp postfix/bounce[9175]: 80593324364: sender non-delivery notification: 43CFE324361 So, it appears to have simply bounced here. – Callmeed Jul 9 '09 at 16:51
Does anyone know how to set this deferral in Postfix? Is it on by default? – Brian Armstrong Sep 10 '09 at 14:27

Getting tempfailed by some other mail server isn't entirely unusual; you should expect this to happen from time to time.

I imagine that most email providers (disclaimer: I only work for ONE) will tempfail things more often for "bad reputation" senders. We do this to selectively prioritise resources for clean(er) mail. If your server has managed to get its IP address a bad reputation, that probably means that messages are being classified as spam either sent by your application, or something else from the same IP address.

You should DEFINITELY monitor your mail queues. You should possibly put some auditing on individual deliveries so you can track them.

If you see large numbers of messages queued for delivery, then that indicates a fault of some kind, either on the recipient's mail server, or that they're blacklisting / de-prioritising your mail in some way.

Exactly how you do these things are application-specific.

In this particular case you should contact Yahoo's support, assuming you think you're definitely not sending them spam (nor is anyone else from the same IP).

share|improve this answer
In addition you might want to place a "Not heard back from us" link were one could enter the email address and check if there was a delivery error or not... It is not really my idea, but something I liked about this one-person shop: – njsf Jul 10 '09 at 4:32

You seem to have two issues here:

  1. What's currently going on with your mail system
  2. How to ensure the problem doesn't happen again in the future

WRT #1, I would do the following checks:

  1. I would setup your server to receive mail. Systems which can't receive bounces, and appear to be broadcast only can often get flagged as spam.
  2. check your MX records and also check if you are on a blacklist -
  3. check your RDNS records at
  4. I would add DomainKeys to your mail server.
  5. I recommend ADDING an SPF record. It can lower your 'spaminess' score, and it can prevent spam hosts as pretending to send mail from your domain.
  6. Send an email to They'll reply with a report with various spam checks.

WRT #2, I would suggest including a transparent gif, or a specially marked logo in your email which will 'phone home', back to your server. Yes, this means you need to send HTML email, and yes, some customers will block emails from retrieving images by default, however, you'll quickly see your normal response rates, and be able to detect if that has dropped. If you have high value customers, and you can see they may not have received your response, you can proactively call them.

share|improve this answer

That looks like a temporary failure. postfix should retry it again after some interval. What's the configuration for postfix look like? Does the message end up in postfix's mail queue? Do you have postfix configured to periodically check for queued messages?

share|improve this answer
The postfix config is probably as default as can be ... I'll dig around and try to look at the settings. – Callmeed Jul 9 '09 at 16:55

You should also make sure that your mail server is identifying itself correctly (as or whatever) and that a PTR record exists linking that IP to that name.

Furthermore, you can add in an SPF record allowing that IP/server to send mail for your domain, so at least it also gets an SPF:Pass.

share|improve this answer
Ok, I will check that out. When identifying itself, does the mail server have to use the same name/domain as the app's URL? The app runs as a subdomain off our primary domain–but on a totally different server. – Callmeed Jul 9 '09 at 17:06
Don't bother with an SPF record, they are of negative benefit stopping spam. Nobody uses them as an indicator of a message not being spam. – MarkR Jul 10 '09 at 4:09
@Callmeed - the PTR record is for the smtp server itself. You can see this if you look at the headers for the message received. It isn't related to the app url. – Adam Brand Jul 10 '09 at 14:41
@MarkR - In our experience, adding an SPF record has prevented messages from ending up in Junk Email folders with Google Apps. – Adam Brand Jul 10 '09 at 14:42
I'd also be suspicious of MarkR's comment, SPF is a good thing in my experience. – Brian Armstrong Sep 10 '09 at 14:39

+1 for recommending SPF record. It is also a good idea to set-up a bounce mail handler.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.