Answers.Body: <p>Avoid using <code>bin/emailprocessor.php</code>, and instead configure your mail processor using the instructions under <em>Configuring inbound email processing</em> on CiviCRM's <a href="http://book.civicrm.org/user/current/advanced-configuration/email-system-configuration/" rel="nofollow">Email system configuration</a> page.</p>
  
  <ul>
  <li>You will create a mailbox accessible via network POP3 or IMAP protocols, not maildir.</li>
  <li>You will configure a <em>Bounce Processing</em> mailbox connection under CiviCRM's Mail Accounts (Administer > CiviMail > Mail Accounts, <code>civicrm/admin/mailSettings</code>) to access this mailbox.</li>
  <li>You will configure CiviCRM's Scheduled Jobs (Administer > System Settings > Scheduled Jobs, <code>civicrm/admin/job</code>) to run the <em>Fetch Bounces</em> Job periodically.</li>
  <li>You will confirm that your system cron configuration is correctly triggering this job to run.</li>
  </ul>
  
  <p>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.</p>
  
  <hr>
  
  <p><a href="http://wiki.civicrm.org/confluence/display/CRMDOC/CiviMail+Processor" rel="nofollow">CiviMail Processor</a> in the CiviCRM wiki has a pink warning box at the top (which is hidden in mobile view): </p>
  
  <blockquote>
    <p><strong>Not Up to Date</strong></p>
    
    <p>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 <a href="http://book.civicrm.org/user/current/advanced-configuration/email-system-configuration/" rel="nofollow">this</a> book page.</p>
  </blockquote>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-23T22:52:22.383Z
Answers.Text: **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.
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-23T17:14:17.903Z
Answers.LastActivityDate: 2015-08-23T22:51:53.580Z
Answers.LastEditDate: 2015-08-23T22:51:53.580Z
Answers.UserDisplayName: Chris Burgess
Answers.Body: <p>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.</p>
  
  <p>The most likely cause(s) for CiviCRM to not know how to handle bounce messages might be:</p>
  
  <ul>
  <li>your mailings do not contain VERP data, or</li>
  <li>your mail system strips this information, or </li>
  <li>your CiviMail configuration doesn't read this correctly.</li>
  </ul>
  
  <hr>
  
  <p>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:</p>
  
  <ul>
  <li>How is your bounce mailbox configured (POP or IMAP? Is it on a flaky dialup connection to head office?)</li>
  <li>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?</li>
  <li>What mail server are you using? This shouldn't be a factor, but it shouldn't hurt to include the information.</li>
  <li>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.)</li>
  </ul>
  
  <p>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: <a href="https://civicrm.stackexchange.com/help/how-to-ask">How do I ask a good question?</a> and <a href="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html" rel="nofollow noreferrer">How to report bugs effectively</a>. Hope this advice will help you move towards a solution!</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-23T14:44:17.207Z
Answers.Text: 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.
Answers.UserDisplayName: Pete Dollimore
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-23T17:08:37.620Z
Answers.Text: OK, that you mention maildir here makes the reason obvious; that's not the recommended approach. Will post a separate answer now.
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-24T18:24:15.823Z
Answers.Text: Correction, ti doesn't in fact call emailprocessor.php (I just read that from the notes!) and indeed it does use cli.php.
Answers.UserDisplayName: Pete Dollimore
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-24T18:31:01.580Z
Answers.Text: Still unsure what docs led you to use maildir. Much simpler to use method documented in the other answer. Good luck!
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-24T19:19:07.250Z
Answers.Text: 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.
Answers.UserDisplayName: Pete Dollimore
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-19T21:26:20.950Z
Answers.LastActivityDate: 2015-08-20T02:26:11.357Z
Answers.LastEditDate: 2017-04-13T12:53:13.167Z
Answers.UserDisplayName: Chris Burgess
Body: <p>My new installation of CiviCRM 4.6.6 is virtually perfect but for one thing I cannot solve.</p>
  
  <p>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".</p>
  
  <p>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".</p>
  
  <p>Can you suggest a solution please?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-18T21:22:15.103Z
Comments.Text: 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).
Comments.UserDisplayName: Chris Burgess
Tags: <civimail><bounce>
Title: Postfix creates email bounces with permissions set to 600, but CiviMAIL doesn't like that!
ThreadText: # Postfix creates email bounces with permissions set to 600, but CiviMAIL doesn't like that!
  
  (Asked by: username_0 on 2015-08-18)
  
  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?
  
  **Tags:** civimail, bounce
  
  > **Comments:**
  > **username_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).  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2015-08-23. Score: 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](http://book.civicrm.org/user/current/advanced-configuration/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](http://wiki.civicrm.org/confluence/display/CRMDOC/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](http://book.civicrm.org/user/current/advanced-configuration/email-system-configuration/) book page.
  
  > **Comments:**
  > **username_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.  
  
  ---
  
  ### Answer by username_1 on 2015-08-19. Score: 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?](https://civicrm.stackexchange.com/help/how-to-ask) and [How to report bugs effectively](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html). Hope this advice will help you move towards a solution!
  
  > **Comments:**
  > **username_0**: 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.  
  > **username_1**: OK, that you mention maildir here makes the reason obvious; that's not the recommended approach. Will post a separate answer now.  
  > **username_0**: Correction, ti doesn't in fact call emailprocessor.php (I just read that from the notes!) and indeed it does use cli.php.  
  > **username_1**: Still unsure what docs led you to use maildir. Much simpler to use method documented in the other answer. Good luck!  
  > **username_0**: 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 username_1.  
  
  ---
  
  