1

My new installation of CiviCRM 4.6.6 is virtually perfect but for one thing I cannot solve.

Incoming bounced messages are handled by the Postfix server and placed in a directory where they are given permission 0600 in other words read and write by the owner only - "civicrm".

When I run the emailprocessor.php it happily deletes those messages but apparently can't read them! If I manually change their permissions before running the script then all is well and the bounces are correctly processed and the users marked "on hold".

Can you suggest a solution please?

Improve this question
1
  • I think you need to be more descriptive of the configuration you've set up for handling incoming bounce messages if you want informed support. Suggest linking to the documentation you've used, and giving as much detail as you can (location of directory where bounces are stored, details of cron configuration, etc).
    – Chris Burgess
    Commented Aug 18, 2015 at 21:22

2 Answers 2

Reset to default
1

Avoid using bin/emailprocessor.php, and instead configure your mail processor using the instructions under Configuring inbound email processing on CiviCRM's Email system configuration page.

  • You will create a mailbox accessible via network POP3 or IMAP protocols, not maildir.
  • You will configure a Bounce Processing mailbox connection under CiviCRM's Mail Accounts (Administer > CiviMail > Mail Accounts, civicrm/admin/mailSettings) to access this mailbox.
  • You will configure CiviCRM's Scheduled Jobs (Administer > System Settings > Scheduled Jobs, civicrm/admin/job) to run the Fetch Bounces Job periodically.
  • You will confirm that your system cron configuration is correctly triggering this job to run.

With a POP3 or IMAP server handling the interaction between CiviCRM and your server's MDA, permissions issues should never arise. The files will be read by the mail system (eg Courier) as an appropriate system user, and will be communicated over the (local) network connection to CiviCRM's bounce fetcher task. Much cleaner.

CiviMail Processor in the CiviCRM wiki has a pink warning box at the top (which is hidden in mobile view):

Not Up to Date

This page isn't up to date anymore as it references a deprecated script: /bin/CiviMailProcessor.php. The new method of handling incoming mail is described on this book page.

Improve this answer
1
  • POP or IMAP? I prefer IMAP, since then CiviCRM puts "unhandled" messages into a separate mailbox which can be reviewed later, and you can point your own mail client at the same IMAP connection to "see" what's happening with bounces.
    – Chris Burgess
    Commented Aug 23, 2015 at 22:52
0

Your description doesn't give much detail to work with. I'm guessing that you may be clearing messages via POP3? If so, CiviCRM might be deleting messages which it can't handle? When using IMAP, CiviCRM should move messages which it doesn't understand to a separate folder. Over POP3 CiviCRM might instead delete the message.

The most likely cause(s) for CiviCRM to not know how to handle bounce messages might be:

  • your mailings do not contain VERP data, or
  • your mail system strips this information, or
  • your CiviMail configuration doesn't read this correctly.

But those are guesses; you are likely to get a much better reply if you increase the level of detail in your question. When reaching out for support, you'll improve your chance of successful request if you provide as many variables and as much data you can, eg:

  • How is your bounce mailbox configured (POP or IMAP? Is it on a flaky dialup connection to head office?)
  • What is the To: address of a bounce message? What do the headers of an email in the bounce mailbox look like before it's deleted?
  • What mail server are you using? This shouldn't be a factor, but it shouldn't hurt to include the information.
  • Anything else that we don't know about your situation? (Assuming the tool works for the majority of installs, you probably need to describe what might be special about your install.)

Often, taking time to gather this and similar information will lead you to solve the problem on your own. A couple of good reads on this topic: How do I ask a good question? and How to report bugs effectively. Hope this advice will help you move towards a solution!

Improve this answer
5
  • The mail account for bounce processing is maildir and, as I've previously explained, when I change the permissions on the mail files in the directory (which happens to be /var/spool/mail/civicrm) the process works fine. In fact I've modified the cron file that calls emailprocessor.php every fifteen minutes to process the bounces with a command to change the permissions of the email files first. But I shouldn't really have to work that "bodge" !! I should be most interested in any technical thoughts.
    – Pete Dollimore
    Commented Aug 23, 2015 at 14:44
  • OK, that you mention maildir here makes the reason obvious; that's not the recommended approach. Will post a separate answer now.
    – Chris Burgess
    Commented Aug 23, 2015 at 17:08
  • Correction, ti doesn't in fact call emailprocessor.php (I just read that from the notes!) and indeed it does use cli.php.
    – Pete Dollimore
    Commented Aug 24, 2015 at 18:24
  • Still unsure what docs led you to use maildir. Much simpler to use method documented in the other answer. Good luck!
    – Chris Burgess
    Commented Aug 24, 2015 at 18:31
  • Correction, my cron wasn't in fact calling emailprocessor.php but it is cli.php. I think I was confused because using the Administer>>System Settings Scheduled Jobs route seems to run emailprocessor.php anyway according to the logs so maybe it's not all that deprecated! But the solution is nigh - thanks to you Chris.
    – Pete Dollimore
    Commented Aug 24, 2015 at 19:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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