1

On my dedicated server, I have Postfix installed for sending email through the websites. One of my clients hosts their email with a third party so we have MX records set up on the domain.

However, when sending any Postfix emails from the server, they do not get the emails. I think since the domain is pointing at the server itself, it tries to send mail to itself, but there is nothing on the server to handle the email for that domain. (There are mail accounts for other domain which are working fine.)

How do I get Postfix to use the domain's MX records to send email? Server is Ubuntu 8.10 with standard LAMP stack. I have Webmin installed, and a control panel called "Matrix" provided by the host.

EDIT: if I try to send email from my own address, I get an error email from the Mail Delivery System, with this error:

<[email protected]>: user unknown. Command output: Invalid user specified.

Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.1.1
Diagnostic-Code: x-unix; Invalid user specified.

Here are the log entries made:

Jan  6 18:06:52 localhost postfix/pickup[29006]: 0329D3F69: uid=33 from=<[email protected]>
Jan  6 18:06:52 localhost postfix/cleanup[30495]: 0329D3F69: message-id=<[email protected]>
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 0329D3F69: from=<[email protected]>, size=611, nrcpt=2 (queue active)
Jan  6 18:06:52 localhost postfix/pipe[30497]: 0329D3F69: to=<[email protected]>, relay=maildrop, delay=0.15, delays=0.1/0/0/0.04, dsn=5.1.1, status=bounced (user unknown. Command output: Invalid user specified. )
Jan  6 18:06:52 localhost postfix/smtp[30498]: 0329D3F69: to=<[email protected]>, relay=gmail-smtp-in.l.google.com[209.85.227.27]:25, delay=0.61, delays=0.1/0.01/0.06/0.45, dsn=2.0.0, status=sent (250 2.0.0 OK 1294337212 o18si30528441wbo.103)
Jan  6 18:06:52 localhost postfix/cleanup[30495]: 868723F75: message-id=<[email protected]>
Jan  6 18:06:52 localhost postfix/bounce[30500]: 0329D3F69: sender non-delivery notification: 868723F75
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 868723F75: from=<>, size=2553, nrcpt=1 (queue active)
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 0329D3F69: removed
Jan  6 18:06:52 localhost postfix/pipe[30497]: 868723F75: to=<[email protected]>, relay=maildrop, delay=0.06, delays=0.01/0/0/0.05, dsn=2.0.0, status=sent (delivered via maildrop service)
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 868723F75: removed
3
  • What shows up in your mail logs when you attempt to send email to that domain?
    – larsks
    Dec 22, 2010 at 15:21
  • What is the result of: - dig mx yourclient.com (from an external client) - dig mx yourclient.com (from your postfix server)
    – lg.
    Dec 22, 2010 at 16:04
  • @lg: Both show the same, correct, MX records. Any more ideas? Jan 6, 2011 at 18:00

4 Answers 4

4
+50

So, I'm bored at work and thought I'd mention the following. I've never used this site before, so, forgive me.

To one of the answers, you commented afterwards to say:

"OK, I have virtual_mailbox_domains = $transport_maps and transport_maps = hash:/etc/postfix/transport. Inside that file is a line that says condorproperties.co.uk maildrop: - should I delete that line? – DisgruntledGoat yesterday"

then followed it with:

"@Devdas: I've tried deleting that line and restarting Postfix, it doesn't fix the problem, do I need to change "maildrop" to something else? – DisgruntledGoat yesterday"

The answer to your first question is, "yes." That line in /etc/postfix/transport was forcing local maildelivery (via maildrop) for email destined for condorproperties.co.uk. Removing it is most appropriate. The problem is simply restarting postfix is insufficient to apply the change.

The problem is, the map as configured in the configuration file, is a hash:/etc/postfix/transport. The file, /etc/postfix/transport is the human-readable version of the file and should have a corresponding /etc/postfix/transport.db - the compiled hashmap - file as well. You use the command postmap to compile the human-readable version into the hashed version. Postfix does check modification times and should be complaining loudly in your logfiles that /etc/postfix/transport.db is out of date. All you need to do is run postmap /etc/postfix/transport so that the change you made before, (removing the line with the condorproperties.co.uk) to take effect. In fact, I don't believe you even have to do a postfix reload for the change to go live once you've issued the postmap command, but it wouldn't hurt.

Long story short, run postmap /etc/postfix/transport then postfix reload.

Cheers.

Btw, the huge clue in your logfiles was this line: Jan 6 18:06:52 localhost postfix/pipe[30497]: 0329D3F69: to=, relay=maildrop, delay=0.15, delays=0.1/0/0/0.04, dsn=5.1.1, status=bounced (user unknown. Command output: Invalid user specified. )

notice, halfway through, where it says relay=maildrop?

1
  • 1
    FANTASTIC first post, thanks!! Compiling the transport map worked a treat and the emails are now working. Jan 9, 2011 at 23:19
1

Can you please paste postconf -n here?

I will bet that you have mydomain.co.uk explicitly listed in one of mydestination, virtual_mailbox_domains, or relay_domains with a transport of maildrop.

ring0 has the idea right, but has parsed the question wrongly, as I understand it. The goal is to get email for one of the domains on the server to go elsewhere, but it's staying with Postfix.

Any mail server will have local configuration override DNS. So if your MTA isn't looking at DNS, you have the domain in your local configuration.

2
  • OK, I have virtual_mailbox_domains = $transport_maps and transport_maps = hash:/etc/postfix/transport. Inside that file is a line that says condorproperties.co.uk maildrop: - should I delete that line? Jan 7, 2011 at 11:15
  • I've tried deleting that line and restarting Postfix, it doesn't fix the problem, do I need to change "maildrop" to something else? Jan 7, 2011 at 12:44
0

postfix follows the standards and performs MX entries resolution of a domain name, in order to find out what server to contact next to transmit the mail.

  • You may have an issue due to the TTL of a domain name (zone), for instance you updated the MX entries at your registrar, but the TTL of that domain makes the previously resolved entry stay in the cache of the domain name server.

  • Also, the domain names on the targeted server may not be declared as local, making the server reject the mails (see the logs, eg /var/log/mail.log) considering your sending server to be trying to relay (spam) via that target server (mydestination in /etc/postfix/main.cf).

Try a dig +nocmd mydomain.tld mx +noall +answer to have easily readable information including TTL from the domains you have a concern with.

1
  • dig shows correct MX records, and it's been a few weeks now so it's all updated properly. Jan 6, 2011 at 18:06
0

Also check that you don't have any custom transports or transport maps somehow defined for the remote domain you intend to send mail to.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .