Answers.Body: <p>Here is an answer that explains the prefix  <a href="https://webmail.west.cox.net/do/mail/message/" rel="nofollow noreferrer">https://webmail.west.cox.net/do/mail/message/</a> that was added to the front of our primary domain. Looking at the CiviMail source for this message (and a number of other similar messages, propagated by copy/paste) the mail source did not specifically set the protocol prefix to "https://". Instead, the source had the default "other". Evidently, most of the ISPs we tested tack just http:// on the front and since we redirect that to https://, everything works. However, the ISP cox.net adds a bit more when the link isn't fully specified. We can't really blame them and there may be different prefixes added by other ISPs. LESSON LEARNED: make sure you add https or http protocol when inserting the contact checksum link (hopefully noone is non-SSL, so it really should be https ;))</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-16T23:55:57.693Z
Answers.LastActivityDate: 2017-01-17T22:35:41.787Z
Answers.LastEditDate: 2017-01-17T22:35:41.787Z
Answers.UserDisplayName: Karl Rudnick
Body: <p>We have been successfully using the contact.checksum link in renewal reminder emails for our Wordpress site. The link in the received email typically looks like: </p>
  
  <p><a href="https://sdbikecoalition.org/?page=CiviCRM&amp;q=civicrm/contribute/transact&amp;reset=1&amp;id=2&amp;cs=yyyyyy&amp;cid=xxx" rel="nofollow noreferrer">https://sdbikecoalition.org/?page=CiviCRM&amp;q=civicrm/contribute/transact&amp;reset=1&amp;id=2&amp;cs=yyyyyy&amp;cid=xxx</a></p>
  
  <p>However, one user has different behavior when opening the email on a webmail client (it will be OK when reading the email in another client). The webmail client is with a local ISP, cox.net. The link has an extra path in the URL, e.g.</p>
  
  <p><a href="https://webmail.west.cox.net/do/mail/message/sdbikecoalition.org/?page=CiviCRM&amp;q=civicrm/contribute/transact&amp;reset=1&amp;id=2&amp;cs=yyyyyy&amp;cid=xxx" rel="nofollow noreferrer">https://webmail.west.cox.net/do/mail/message/sdbikecoalition.org/?page=CiviCRM&amp;q=civicrm/contribute/transact&amp;reset=1&amp;id=2&amp;cs=yyyyyy&amp;cid=xxx</a></p>
  
  <p>This seems to be CLEARLY the fault of the ISP. The SAME email, when forwarded to another mail provider is correct. The user with this problem has talked to their ISP (cox.net) and they cannot provide an answer.</p>
  
  <p>I'm just posting to see if anyone has encountered something like this with either cox.net or any other ISP.</p>
  
Tags: <civimail><scheduled-reminders><checksum>
Title: Renewal link mangled by webmail client with ISP
ThreadText: # Renewal link mangled by webmail client with ISP
  
  (Asked by: username_0 on 2017-01-12)
  
  We have been successfully using the contact.checksum link in renewal reminder emails for our Wordpress site. The link in the received email typically looks like:
  
  <https://sdbikecoalition.org/?page=CiviCRM&q=civicrm/contribute/transact&reset=1&id=2&cs=yyyyyy&cid=xxx>
  
  However, one user has different behavior when opening the email on a webmail client (it will be OK when reading the email in another client). The webmail client is with a local ISP, cox.net. The link has an extra path in the URL, e.g.
  
  <https://webmail.west.cox.net/do/mail/message/sdbikecoalition.org/?page=CiviCRM&q=civicrm/contribute/transact&reset=1&id=2&cs=yyyyyy&cid=xxx>
  
  This seems to be CLEARLY the fault of the ISP. The SAME email, when forwarded to another mail provider is correct. The user with this problem has talked to their ISP (cox.net) and they cannot provide an answer.
  
  I'm just posting to see if anyone has encountered something like this with either cox.net or any other ISP.
  
  **Tags:** civimail, scheduled-reminders, checksum
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2017-01-16. Score: 3 | Accepted answer
  
  Here is an answer that explains the prefix <https://webmail.west.cox.net/do/mail/message/> that was added to the front of our primary domain. Looking at the CiviMail source for this message (and a number of other similar messages, propagated by copy/paste) the mail source did not specifically set the protocol prefix to "https://". Instead, the source had the default "other". Evidently, most of the ISPs we tested tack just http:// on the front and since we redirect that to https://, everything works. However, the ISP cox.net adds a bit more when the link isn't fully specified. We can't really blame them and there may be different prefixes added by other ISPs. LESSON LEARNED: make sure you add https or http protocol when inserting the contact checksum link (hopefully noone is non-SSL, so it really should be https ;))
  
  
  ---
  
  