Re: [mailop] Mimecast Adimin Probation Block - 74.203.49.59
On Thu 29/Jun/2023 04:46:35 +0200 Sebastian Nielsen via mailop wrote:
See RFC 8058 on doing one-click unsubs in a way unlikely to be mistriggered.
Its a good idea, but don't count on all MUAs implementing this function, so
best here is to have both, if request arrives from the RFC 8058 header, treat
it as secure enough to warrant one-click, but if it arrives through the
unsubscribe link in the email itself, require an extra click on button.
It can well be the same form. In PHP:
if (isset($_POST["List-Unsubscribe"]) &&
$_POST["List-Unsubscribe"] == "One-Click")
{
// do the unsubscribe
if ($ok)
{
http_response_code(202);
return $address ." successfully unsubscribed";
}
http_response_code(500);
return $bad;
}
http_response_code(200);
return '
Manual unsubscribe
Enter "One-Click",
see https://www.rfc-editor.org/rfc/rfc8058;>RFC
8058
';
Best
Ale
--
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Mimecast Adimin Probation Block - 74.203.49.59
>>See RFC 8058 on doing one-click unsubs in a way unlikely to be mistriggered. Its a good idea, but don't count on all MUAs implementing this function, so best here is to have both, if request arrives from the RFC 8058 header, treat it as secure enough to warrant one-click, but if it arrives through the unsubscribe link in the email itself, require an extra click on button. Thus those with non-RFC8058-aware MUAs can still unsubscribe, but it will require an extra click. Some MUAs implement RFC 8058 through their Junk button, so you actually have to click Junk to trigger RFC 8058, which then both reports the mail as Junk but also triggers a RFC 8058 Post. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mimecast Adimin Probation Block - 74.203.49.59
It appears that Grant Taylor via mailop said: >On 6/28/23 11:07 AM, Chris Truitt via mailop wrote: >> The Mimecast spam checking appears to be clicking every link. This has >> inadvertently caused an uptick in Unsubscribes. > >Aside: Isn't this why the unsubscribe links are encouraged to use / >require a POST so that simple GETs don't accidentally trigger the >unsubscribe? Yes indeed. Lots of mail systems fetch all the URLs as part of spam filtering, so if you misinterpret them you have worse problems than Mimecast. See RFC 8058 on doing one-click unsubs in a way unlikely to be mistriggered. You can require an extra click but that is more annoying to the users than POST, and we are doing you a favor by unsubbscribing (the junk button is always one click) so it is in your interest to make it as easy as possible. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mimecast Adimin Probation Block - 74.203.49.59
No, but a 2-step procedure is recommended. Click the link, then push a button to confirm. Some actors also require a checkbox, to really make sure link-following bots don't confirm. Or even a simple captcha. Don’t neccessarly need to use POST, but scanning systems scan the links to ensure no malicious software is there or similar. So just making the unsubscribe request in a second link is enough, scanning bots don't follow more than 1 step in most cases, and for 2-step following bots, a checkbox is enough to veer them off. If they feel the urge of following subsequent links to check for malice, they will also follow POST based links, else malware actors could just hide everything behind a POST. POST/GET is only to prevent certain caching and reloading behaviour to affect things on a server, for example, reloading a page might delete something or similar. -Ursprungligt meddelande- Från: Grant Taylor via mailop Skickat: den 28 juni 2023 22:22 Till: mailop@mailop.org Ämne: Re: [mailop] Mimecast Adimin Probation Block - 74.203.49.59 On 6/28/23 11:07 AM, Chris Truitt via mailop wrote: > The Mimecast spam checking appears to be clicking every link. This has > inadvertently caused an uptick in Unsubscribes. Aside: Isn't this why the unsubscribe links are encouraged to use / require a POST so that simple GETs don't accidentally trigger the unsubscribe? Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mimecast Adimin Probation Block - 74.203.49.59
On 6/28/23 11:07 AM, Chris Truitt via mailop wrote: The Mimecast spam checking appears to be clicking every link. This has inadvertently caused an uptick in Unsubscribes. Aside: Isn't this why the unsubscribe links are encouraged to use / require a POST so that simple GETs don't accidentally trigger the unsubscribe? Grant. . . . ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mimecast Adimin Probation Block - 74.203.49.59
Replied offline. From: mailop on behalf of Chris Truitt via mailop Date: Wednesday, June 28, 2023 at 12:11 PM To: Dave Smith via mailop Subject: [mailop] Mimecast Adimin Probation Block - 74.203.49.59 Hi Dave, We're getting a Mimecast Admin Probation Block. The Mimecast spam checking appears to be clicking every link. This has inadvertently caused an uptick in Unsubscribes. smtp;550 Administrative prohibition - envelope blocked - https://community.mimecast.com/docs/DOC-1369#550 [2TjxbsUyNyGkZn1qelpfdQ.uk8]. Sending IP: 74.203.49.59 While the SMTP error on the Mimecast site indicates an issue with the SPF record, our tests prooves this to be false. Are you the appropriate contact to help me with this? If not would you mind pointing me in the right direction? Thanks in advance, Chris Truitt ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
