1

I have postfix and dovecot installed on a Centos 6.4 production (www.bw.co.uk) machine. The intent is to send all system and transactional messages and collect bounces. The email id's that resulted in a bounce are then flagged to prevent site from sending further messages to these id's.

I have the necessary SPF records setup on the DNS and PTR records setup on my hosting providers end. My MX records point to a different mail server where our staff sends and receives email.

My issue is though I have been able to send mail from the production machine I am unable to read bounces using my php snippet. Actually I do not even know if the bounces are reaching the machine!

I have a similar setup on my test (www.st.biz) machine with the same hosting provider the MX, SPF and PTR records are setup in a similar fashion i.e. the MX records point to another mail server where the staff sends and receives mail. On the test machine I am able to read the bounces using the PHP program.

The postfix logs /var/log/maillog on the production machine indicates a single bounce which was not initiated by the php program that send out the transactional messages Mar 3 03:15:03 bw postfix/smtp[22338]: 09420120CA3: to=, relay=mail.st.in[999.999.999.999]:25, delay=0.9, delays=0.05/0.02/0.43/0.41, dsn=4.7.1, status=deferred (host mail.st.in[999.999.999.999] said: 451 4.7.1 Please try again later (in reply to DATA command))

Any idea what could be wrong?

sridhar pandurangiah
  • 763
  • 2
  • 11
  • 29
  • Your mail was tried for delivery and kept in deferred queue since the remote MTA told to retry sending later. So postfix will try to deliver the mail until maximal_queue_lifetime expires. More info here http://www.postfix.org/QSHAPE_README.html#deferred_queue – clement Mar 03 '14 at 03:39

2 Answers2

2

Bounces will be returned to the relay system. You must arrange for it to forward the bounces back to your system for processing. It may be simpler to process the bounces on it than getting the bounces forwarded back to your system.

Do use a specific sending email address of the form "donotreploy@example.com". It should be in an appropriate domain or sub-domain for your application.

In normal processing, you can expect some email to remain queued for a long time before being bounced. Normally, this will be in the range of 4 to 7 days.

Some systems will accept the mail before deciding whether to deliver it or not. If they are well behaved you will not see bounces from them as they would risk generating backscatter spam if they did send a bounce message.

EDIT: I would expect your email to be sent using the MX server which appears to be a different server than your web server. (Email sent from www. domains is unusual, and in my experience likely spam.) Using a second domain on the same server to send mail might be more appropriate. Neither of the domains you describe appear to be valid, so I can't verify your configuration.

If you want the bounces to remain on your web server, use it as the MX for itself, or just omit the MX record. Configure a postmaster address that can be used to send information back about configuration issues. Likewise an abuse address is recommended so that abuse reports can be sent to you. Both of these can be forward to users on the MX domain you refer to.

BillThor
  • 27,737
  • 3
  • 37
  • 69
  • I do not use a separate relay system. Postfix is installed on the same server as the saas app and the domain mail.bw.co.uk points to the same machine. FYI : " If they are well behaved you will not see bounce.." I have a set of id's that I use that result in a bounce. I am able to see bounces from these addresses almost immediately on the test machine. "In normal processing, you can expect some email to remain queued for a long time before being bounced" - Waited for over a week! – sridhar pandurangiah Mar 03 '14 at 05:30
  • We're currently using a subdomain (**mail.**)that points to the same ip as the www to send out emails. We'll plan to move it to a smarthost in due course. I thought mentioning the domains on the post was inappropriate so had to abbreviate them. Nevertheless here you go - www.bookingwire.co.uk and mail.bookingwire.co.uk (live servers), sastratechnologies.biz and mail.sastratechnologies.biz (test servers). I have configured an **abuse** address will configure a **postmaster** address rightaway. – sridhar pandurangiah Mar 04 '14 at 06:12
  • Created the postmaster account. The bounced mails do not get delivered to the postmaster. – sridhar pandurangiah Mar 05 '14 at 07:44
  • Postmaster account is to enable administrators of other domains to contact your mail administrators. It should not be receiving bounce messages. Bounce messages will be sent back to the sending userid. – BillThor Mar 06 '14 at 01:30
1

Bill is right about the MX record causing the non returned mail. Basically, although SPF allows you to send mail, and the PTR record confirms it, the MX record pointing to another server means bounces will be sent back there.

When the remote mail server has to bounce the email, it will do an MX lookup on your domain, and it will send the email to that record. So, all your bounces will be headed back to that server.

You could create a subdomain on your server, then create an alias on the machine with the MX record, postmaster@domain.com => postmaster@sub.domain.com. That way you will receive all the bounces.

NickW
  • 10,263
  • 1
  • 20
  • 27
  • I have a similar setup on my test servers. I don't have this issue on the test machine. – sridhar pandurangiah Mar 05 '14 at 17:05
  • Just to drive home my point I have pasted the DNS entries **[here](http://pastebin.com/embed_iframe.php?i=ZbmZNYdc)** – sridhar pandurangiah Mar 05 '14 at 17:18
  • Why not read the RFCs? If the server that has to generate the bounce record (which is NOT a must) it will reply to the sender, if the domain of the sender has an MX record, the bounce record will be sent there! If the bounces are arriving on your test server, you need to find out what about your test server with the MX record is relaying them back, or if they are actually generated by your test server's postfix instance (for example, sending to remote destination timed out, or remote server replied with a 550). – NickW Mar 05 '14 at 17:22
  • I am doing just that. Will post back in a few hours – sridhar pandurangiah Mar 05 '14 at 17:27
  • Just an FYI, I may reply tomorrow ;) – NickW Mar 05 '14 at 17:30
  • Knocked-off the MX records that were pointing to external service, tested, No luck. Included an MX record to point to the host, tested, no luck. Created the DNS records like those available for the DNS server i.e. MX -> mx1.bookingwire.co.uk -> mail.bookingwire.co.uk (CNAME) -> 146.185.133.41 (A), tested, no luck. Will create a fresh mail host on a new VPS and check. – sridhar pandurangiah Mar 06 '14 at 12:26
  • What was the TTL on that domain? Are you sure you waited until the cached MX records would have timed out? – NickW Mar 06 '14 at 12:28
  • It seems funny but the web interface of the regisrar 123-reg.co.uk doesn't display the TTL figures! Yes I did wait. Did a dig before I commenced a test. Will run two more tests before embarking on a new installation. Plan to test in 3 hours from now. – sridhar pandurangiah Mar 06 '14 at 12:33
  • Not a criticism, just something that's caught me out before :) – NickW Mar 06 '14 at 12:45