Answers.Body: <p>It's hard to imagine how the hash could be corrupted in transit, but easier to imagine how it could be overwritten in the database.  I recommend enabling advanced logging (<strong>Administer menu » System Settings » Misc</strong>) so that you can see the old values of records in <code>log_civicrm_mailing_event_queue</code>.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-08-04T04:43:09.147Z
Answers.Text: Since adding the 'report error' extnsion we are identifying a lot of these and are stumped with how to identify why some are going out without all the necessary parameters. will upgrade soon and see if that stops them but haven't spotted anything that suggests a fix has been done
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-31T02:12:44.563Z
Answers.Text: @Jon G - Actually advanced logging does not help, because it ignores all of the civicrm_mailing_event_* tables. Which is probably a good thing since they would grow very large very quickly, but provides no clues in this situation.
Answers.UserDisplayName: twowheeler
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-10-31T15:15:11.313Z
Answers.Text: Ah - good point.  But also this code is getting a major rewrite - the `civicrm_mailing_event_*` tables are going away soon, e.g. https://github.com/civicrm/civicrm-core/pull/27557.  Might be worth reassessing in Civi 5.67 and 5.68.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-01-18T22:14:39.717Z
Answers.LastActivityDate: 2022-01-18T22:14:39.717Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>I am seeing errors with optouts and unsubscribes similar to <a href="https://civicrm.stackexchange.com/questions/39300/civimail-loss-of-opt-out-unsubcribe-forwarding/40801#40801">this</a>. It is inconsistent - some requests succeed but some fail with &quot;There was an error in your request&quot; as described there. The query string on the optout or unsubscribe looks like: &quot;jid=3292&amp;qid=1930772&amp;h=b600fd5ef64ce4b4&quot;. Doing a DB query I can find the matching 'id' and 'job_id' in the civicrm_mailing_event_queue table, but the hash does not match, so the attempt to verify the parameters produces the error. So it seems as though in these cases the hash value is either corrupted in transit or is overwritten in the database. I'd be interested to know if anyone else can validate that behavior. Thanks. This is on CiviCRM 5.43.0 and Wordpress 5.8.2, with flexmailer and mosaico enabled.</p>
  <p>Edit: just to be clear, the returned hash value does not exist anywhere in the civicrm_mailing_event_queue table so I don't know how it is being generated.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-09-11T12:11:35.660Z
Comments.Text: I have a similar issue, except I can't even find the job_id in civicrm_mailing_event_queue!
Comments.UserDisplayName: artfulrobot
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-10-20T21:26:13.080Z
Comments.Text: Now almost two years later I am still seeing these errors, so I started tracking them in a spreadsheet. I modified the code so the error message would contain the job, queue and hash IDs. Today a mailing went out to about 4,000 emails, and the opt-out page was hit 17 times so far. Two were successful and were recorded in the opt-out report. Six others had a bad hash ID but could be identified based on the queue ID. One had only a bad hash, and no other parameters. Four more have what appear to be random query strings, and the last 4 have no query strings after the reset parameter.
Comments.UserDisplayName: twowheeler
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-10-20T21:34:46.907Z
Comments.Text: Those last 9 seem likely to be automated abuse of some kind, but the six with two good parameters and a bad hash are the puzzle. The data is at https://docs.google.com/spreadsheets/d/11bPd4rG6cT8wXjZL6U-94SfzsSHYZ2sIfhn6-7ScLqQ/edit?usp=sharing
Comments.UserDisplayName: twowheeler
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-10-23T07:39:04.567Z
Comments.Text: I hardly ever hear of people complaining that they can't unsubscribe. So hopefully this is just weirdness that comes from automated systems misbehaving - by accident or otherwise. It is annoying though!
Comments.UserDisplayName: artfulrobot
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-10-23T09:45:44.927Z
Comments.Text: Well, I do hear such complaints. "Your unsubscribe doesn't work, I tried it 3 times." At that point they are writing an angry email to the director.
Comments.UserDisplayName: twowheeler
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-10-24T11:15:33.890Z
Comments.Text: Right, not good! I'm fairly convinced that it's *generating* the right links. But there's still room for content authors to do something daft like follow a URL with a full stop/punctuation, and for all manor of systems to interfere/break the links along the way. There's also link expiry to consider - sometimes people try to use an old one. Perplexing.
Comments.UserDisplayName: artfulrobot
Tags: <civimail><flexmailer>
Title: Errors on opt out or unsubscribe
ThreadText: # Errors on opt out or unsubscribe
  
  (Asked by: username_0 on 2021-12-03)
  
  I am seeing errors with optouts and unsubscribes similar to [this](https://civicrm.stackexchange.com/questions/39300/civimail-loss-of-opt-out-unsubcribe-forwarding/40801#40801). It is inconsistent - some requests succeed but some fail with "There was an error in your request" as described there. The query string on the optout or unsubscribe looks like: "jid=3292&qid=1930772&h=b600fd5ef64ce4b4". Doing a DB query I can find the matching 'id' and 'job\_id' in the civicrm\_mailing\_event\_queue table, but the hash does not match, so the attempt to verify the parameters produces the error. So it seems as though in these cases the hash value is either corrupted in transit or is overwritten in the database. I'd be interested to know if anyone else can validate that behavior. Thanks. This is on CiviCRM 5.43.0 and Wordpress 5.8.2, with flexmailer and mosaico enabled.
  
  Edit: just to be clear, the returned hash value does not exist anywhere in the civicrm\_mailing\_event\_queue table so I don't know how it is being generated.
  
  **Tags:** civimail, flexmailer
  
  > **Comments:**
  > **username_1**: I have a similar issue, except I can't even find the job_id in civicrm_mailing_event_queue!  
  > **username_0**: Now almost two years later I am still seeing these errors, so I started tracking them in a spreadsheet. I modified the code so the error message would contain the job, queue and hash IDs. Today a mailing went out to about 4,000 emails, and the opt-out page was hit 17 times so far. Two were successful and were recorded in the opt-out report. Six others had a bad hash ID but could be identified based on the queue ID. One had only a bad hash, and no other parameters. Four more have what appear to be random query strings, and the last 4 have no query strings after the reset parameter.  
  > **username_0**: Those last 9 seem likely to be automated abuse of some kind, but the six with two good parameters and a bad hash are the puzzle. The data is at https://docs.google.com/spreadsheets/d/11bPd4rG6cT8wXjZL6U-94SfzsSHYZ2sIfhn6-7ScLqQ/edit?usp=sharing  
  > **username_1**: I hardly ever hear of people complaining that they can't unsubscribe. So hopefully this is just weirdness that comes from automated systems misbehaving - by accident or otherwise. It is annoying though!  
  > **username_0**: Well, I do hear such complaints. "Your unsubscribe doesn't work, I tried it 3 times." At that point they are writing an angry email to the director.  
  > **username_1**: Right, not good! I'm fairly convinced that it's *generating* the right links. But there's still room for content authors to do something daft like follow a URL with a full stop/punctuation, and for all manor of systems to interfere/break the links along the way. There's also link expiry to consider - sometimes people try to use an old one. Perplexing.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2022-01-18. Score: 1
  
  It's hard to imagine how the hash could be corrupted in transit, but easier to imagine how it could be overwritten in the database. I recommend enabling advanced logging (**Administer menu » System Settings » Misc**) so that you can see the old values of records in `log_civicrm_mailing_event_queue`.
  
  > **Comments:**
  > **username_3**: Since adding the 'report error' extnsion we are identifying a lot of these and are stumped with how to identify why some are going out without all the necessary parameters. will upgrade soon and see if that stops them but haven't spotted anything that suggests a fix has been done  
  > **username_0**: @Jon G - Actually advanced logging does not help, because it ignores all of the civicrm_mailing_event_* tables. Which is probably a good thing since they would grow very large very quickly, but provides no clues in this situation.  
  > **username_2**: Ah - good point.  But also this code is getting a major rewrite - the `civicrm_mailing_event_*` tables are going away soon, e.g. https://github.com/civicrm/civicrm-core/pull/27557.  Might be worth reassessing in Civi 5.67 and 5.68.  
  
  ---
  
  