2

Our Linux host (CentOS) has several shared domains, one of which is example.com (fake host and user names used throughout this message); We use /etc/mail/virtusertable to have all mail to example.com delivered to the "exmpl" user, and ~exmpl/.procmailrc forwards mail as appropriate. This method allows exmpl to maintain their own forwardings, which /etc/mail/aliases does not. Actually, virtusertable has known recipients for example.com, and rejects mail to unknown recipients. We learned that lesson long ago.

However, mail forwarded in this way was failing:

Apr 30 21:33:30 bogus sendmail[25645]: r412XUQ8025645: [email protected], ctladdr=exmpl (504/504), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30965, relay=[127.0.0.1] [127.0.0.1], dsn=5.6.0, stat=Data format error

This seemed quite strange, because "person" is a valid user on bogus.org, and in fact bogus.org is the main domain on the same machine as example.com!

How can we fix this?

4
  • Please don't mark this as SOLVED in the title. Write up your answer as an answer and then mark it as the accepted answer instead. Can you please correct this?
    – slm
    May 12, 2013 at 18:11
  • @slm New users have to wait 8 hours before answering their own question. May 12, 2013 at 18:34
  • @MichaelHampton. Thanks. Sorry I should have mentioned that in my comments.
    – slm
    May 12, 2013 at 18:47
  • Thanks, folks - looks like @JoelCoel fixed it for me! (newbie error, sorry)
    – whbjr
    May 12, 2013 at 19:10

2 Answers 2

2

Many others have solved this by fixing the "localhost" entry in /etc/hosts and/or setting up appropriate DNS entries. We did that, and it didn't fix our problem.

We finally noticed this: ctladdr=exmpl For mail which was correctly delivered, those log entries showed that as a full email address, e.g. ctladdr=<[email protected]> What was missing was this important entry in virtusertable:

[email protected] exmpl

I don't claim to fully understand this (this counts as my question!) because to me it looks like a "backwards" use of virtusertable. However, mail forwarded as above is now working!

May  6 21:06:40 bogus sendmail[1482]: r4726ejj001480: to=<[email protected]>, ctladdr=<[email protected]> (504/504), delay=00:00:00, xdelay=00:00:00, mailer=local, pri=62862, dsn=2.0.0, stat=Sent
1
  • Thanks for straightening out my asked-and-answered post!
    – whbjr
    May 12, 2013 at 19:12
1

It is usually clearer what the problem is if you telnet to the MX server on port 25 and initiate a manual SMTP conversation.

In the example above where ctladdr=exmpl, if you entered this as the MAIL FROM, the MX server would have told you that the domain does not exist and that's why it can't accept your mail. I've had the problem where somedomain.com is defined in DNS and used for web traffic, but Apache tries to send mail as [email protected], and doing a manual SMTP conversation will reveal that the MX server can't findwww.somedomain.com.

The solution then is to add an A or CNAME record for this subdomain.

1
  • sometimes TLS is required and so you cannot use telnet... but an alternative utility that works great is SWAKS (jetmore.org/john/code/swaks)
    – TekOps
    Mar 1 at 22:30

You must log in to answer this question.

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