-   Linux - Server (
-   -   Postfix Queue (

carlosinfl 03-03-2009 02:25 PM

Postfix Queue
I am noticing that for some reason everytime a specific user on my domain attempts to email a particular domain, the messages are always queued up. They don't ever appear to send for some reason and I checked the logs which don't really give any specific reason why I can't send email to this domain. Do you guys know by looking at what I can see on my end if this problem is caused by something on my end?


mail:~# postqueue -p
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
4DB191FA4D50    84627 Mon Mar  2 14:59:56
            (connect to[]:25: Connection timed out)

557E41FA4D30    84155 Mon Mar  2 08:19:14
            (connect to[]:25: Connection timed out)

CFD8F1FA4D4E    84627 Mon Mar  2 14:59:55
    (connect to[]:25: Connection timed out)
      (connect to[]:25: Connection timed out)

C9EA81FA4D33    84155 Mon Mar  2 08:19:15
        (connect to[]:25: No route to host)
      (connect to[]:25: Connection timed out)

054741FA4D55    2029 Mon Mar  2 12:16:04
            (connect to[]:25: Connection timed out)

-- 352 Kbytes in 5 Requests.

dkm999 03-03-2009 04:40 PM

There are a couple of possibilities here:
1. You are trying to send mail to a non-existent host
2. You are trying to send mail to a host that is ignoring you.

I used nslookup to verify the address your queue is showing, and it does correspond to But a request for the mail-exchangers for does not indicate that this host should be receiving mail. The mail-exchangers for that domain are

So this problem resolves into a new one: how did your Postfix come up with the name to send messages to? Did the user explicitly specify that host as a target? Or did Postfix get bad info from its DNS lookup of MX records? Or did something else happen to misdirect these messages? Only a good look at the mail headers for the offending messages will tell you that. When a message finally expires and is sent back to its originator (or to the postmaster), you will need to examine the headers to see at what stage of forwarding a host made the choice to use the wrong mail exchanger. Then further work will be needed to figure out why.

Good luck.

carlosinfl 03-04-2009 08:30 AM

When I go to my Postfix email server, I checked to see what it resolves as follows:


mail:~# host                A

I then ran the same command against what you noted above are the correct mail exchanges for that domain:


mail:~# host            A

It appears that address is totally different. What do you think is the problem here? I don't understand...

dkm999 03-04-2009 01:20 PM

As you discovered, there are correct resolutions for the names of both hosts, so that is not a problem. But in order to accept mail for delivery, would have to be listening on TCP port 25, which it very likely is not doing, either because it has been configured not to accept mail, or because there is an intervening firewall that is preventing it from hearing your request.

Postfix (and other mail-transfer agents) follows this protocol in sending mail.

1. Look for a DNS MX record for the specific host (not an A record).
2. If that is found, use it. Otherwise, lop off the leading part of the DNS name, and look for a DNS MX record for the subdomain.
3. Continue this process until an MX record is found.

In this case, the correct process would be to look first for an MX record for When that fails, the next step should be to look for an MX record for If that fails, look for one for .mil, which will probably fail as well, since it is pretty unlikely that anyone would offer to accept mail for an entire top-level domain.

This process can be complicated by the fact that mail-transfer agents cache previously-used MX records, and will use them if nothing else is found.

So, in your case, I recommend that you check if your resolver can deliver the correct MX record when asked

set type=mx
{should time out}
{should report 2 MX records}

This test will eliminate local DNS problems as a source for the deferral you first reported. Then, as I suggested in my previous post, examine the mail headers when the e-mail finally bounces to see where the message has gone, and how it was directed for further clues as to what has gone wrong.

All times are GMT -5. The time now is 12:17 PM.