I'm building a small ticket system where basically some mail accounts of my email server are piped into a PHP script that will take care of the emails.

The server is running, I can send email over SMTP without any issues, I can also receive them on the users virtual mailboxes and access them over IMAP.

However, there's a problem, I'm using this rule to pipe the emails:

smtpd_recipient_restrictions = check_recipient_access mysql:/etc/postfix/mysql-virtual-recipient-access.cf, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination

Bassically the SQL query referenced on /etc/postfix/mysql-virtual-recipient-access.cf returns the following every time its supposed to pipe a specific mailbox to PHP:

FILTER ticket:dummy

And then I've a hook defined at master.cf like this:

ticket unix - n n - - pipe
    flags=F user=www-data argv=/webroot/tiketman/AppCore/Mail/Incoming.php ${sender} ${size} ${recipient}

This setup works fine if I send and email from an address inside or outside my server, however bounces like Mail Delivery Notifications originated on my server such as

<error@sfasdadf.com>: Host or domain name not found. Name service error for
    name=sfasdadf.com type=A: Host not found

Don't get filtered and aren't not piped to PHP ending up on the user mailbox.

Here is /var/log/mail.log on sending a test email and receiving the error back:

Sep 19 23:09:11 mail postfix/smtp[8773]: 764E2409DF: to=<email@sfasdadf.com>, relay=none, delay=0.14, delays=0.11/0.01/0.02/0, dsn=5.4.4, status=bounced (Host or domain name not found. Name service error for name=sfasdadf.com type=A: Host not found)
Sep 19 23:09:11 mail postfix/cleanup[8771]: 970D2409E1: message-id=<20140919210911.970D2409E1@mail.ptdyncs.com>
Sep 19 23:09:11 mail postfix/bounce[8774]: 764E2409DF: sender non-delivery notification: 970D2409E1
Sep 19 23:09:11 mail postfix/qmgr[8638]: 970D2409E1: from=<>, size=3583, nrcpt=1 (queue active)
Sep 19 23:09:11 mail postfix/qmgr[8638]: 764E2409DF: removed
Sep 19 23:09:11 mail dovecot: lmtp(8777): Connect from local
Sep 19 23:09:11 mail dovecot: lmtp(8777, test-1@ptdyncs.com): FXZGJnebHFRJIgAAvu7YNA: msgid=<20140919210911.970D2409E1@mail.ptdyncs.com>: saved mail to INBOX
Sep 19 23:09:11 mail postfix/lmtp[8776]: 970D2409E1: to=<test-1@ptdyncs.com>, relay=mail.ptdyncs.com[private/dovecot-lmtp], delay=0.04, delays=0.01/0.01/0.01/0.02, dsn=2.0.0, status=sent (250 2.0.0 <test-1@ptdyncs.com> FXZGJnebHFRJIgAAvu7YNA Saved)
Sep 19 23:09:11 mail dovecot: lmtp(8777): Disconnect from local: Client quit (in reset)
Sep 19 23:09:11 mail postfix/qmgr[8638]: 970D2409E1: removed

How can I fix this, without changing much the architecture of this thing, because I need to be able to set the hook that will process the messages (or none) at SQL for each virtual user. Thank you.

  • I wish the person who voted this down could give some feedback! I'm no expert that's why I'm asking for help ;) – TCB13 Sep 20 '14 at 2:12

Yup that is intended behavior. Your bounce doesn't pass check_recipient_access because smtpd directive and from your log, the bounce email never touch smtpd at all (bounce -> qmgr -> lmtp)

One possible solution of your problem is using transport_maps instead of check_recipient_access. This directive was invoked by trivial-rewrite process and all email should passing this special process whether the email is bounce, smtpd or pickup. This method have some caveats as explained later.

For this method going to work you should modify the SQL query so it returns


instead of

FILTER ticket:dummy

for your special user.

The caveats of this method is your mysqld MUST NOT be unreachable, ever at all. SQL server dead = No mail flow. You can view some advice regarding this matter in this thread.

  • If you remove check_recipient_access and the email become rejected please add postconf -n output in your question so we can view the complete picture of your setup – masegaloeh Sep 20 '14 at 14:15
  • If I go this solution, will bounces for virtual users not piped into the process still arrive to their mailboxes? Or every bounce will end up on the pipe? Thank you for answering the question, I was almost sure this was intended behavior, but still looking for a way around. ;) – TCB13 Sep 20 '14 at 17:53
  • 1
    Yes it will arrive in lmtp process instead go to pipe. Your query must be modified, for ordinary use, it will return none. For example select ticket:dummy from sometable where special_user=1 – masegaloeh Sep 20 '14 at 21:45
  • If this answer solves your problem, you can safely remove your other question. Basically it's has same purpose with this question. – masegaloeh Sep 21 '14 at 1:40
  • Done ;) The other one was more specific, I was thinking about remove this one previously. – TCB13 Sep 21 '14 at 2:13

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

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