The mailing list for listmasters using Sympa

[Steve Rich <address@concealed>]

Thanks Steve.  Preliminarily, this seems like it should work in 6.2 with some tweaking.  I just got our test environment fixed so I will work on testing this tomorrow.  I'll keep you posted.

Thanks,

Steve

From: Steve Shipway <address@concealed>
Sent: Oct 12, 2015 18:41
To: Steve Rich; address@concealed
Subject: RE: Footer unsubscribe link

We had this problem as well, particularly for the one-time-ticket URLs.

 

Gmail will pre-fetch links when clicked on to scan them for malware, then will redirect the user to the actual link – so it appears to Sympa to have been clicked on twice, and the ticket is now invalid.

 

With Office365 it sounds even worse as the URLs are prefetched even if they are not clicked on, giving the result you are experiencing.  This can also happen with some browser add-ins we have discovered.

 

The way we worked around this in 6.1 was to create a custom action – confirm_ticket – which would require a button click to go to the actual one-time-ticket path.  Then, the notification emails that would contain the one-time-ticket URL were customised to instead point the user to the confirm_ticket custom action URL (but with the one-time-ticket ID as a parameter).  This made it a two-step process and avoided the problem.

 

Unfortunately, this will not work the same way under Sympa 6.2 as the custom actions are now configured differently.  However, it would certainly be possible to do a similar thing under 6.2, and we are in the process of porting our customisations over.

 

However it should be possible to do something similar to our confirm_ticket custom action; setting up a custom action that takes the same parameters and requires a single-click confirm to redirect the user to the ‘real’ unsubscribe link.  Note we can’t use a list custom action as this may require the user to be authenticated to access it.

 

This would work by making the unsubscribe link in your list footer something like:

[% wwsympa_url %]/ca/confirm_signoff/[% listname %]/[% user.escaped_email %]

 

Then, you would make a minimal custom action custom_actions/confirm_signoff.pm a bit like this

 

package confirm_signoff_plugin;

use strict;

sub process {

    my( %stash ) = ();    # variables to pass back to TT2 template

    return 'home' if(ref $_[0]); # Must not run in list context

    $stash{'signoff_list'} = $_[0];

    $stash{'signoff_email'} = $_[1];

    return \%stash;

}

1;

 

Finally, a web_tt2/confirm_signoff.tt2 containing something like:

 

<div class="block">

<h2>[%|loc%]Confirm List Signoff[%END%]</h2><br />

<P>To signoff from the list, please click below:</P>

<P><a class="actionMenuLinks" href=""[%" path_cgi %]/auto_signoff/[% signoff_list %]/[% signoff_email %]">Confirm Signoff</a></P>

</div>

 

Note that I haven’t tested this but it will probably work under 6.2.  Best practice would probably be to add a few more things in the confirm_signoff.tt2 to verify the content of the signoff_list and signoff_email variables and produce the appropriate error if they are not set.

 

Please let me know if you try this out, and if it works for you

 

Steve

 

Steve Shipway

T: +64 9 3737 599 ext 86487

E: address@concealed

(GNU Terry Pratchett)

 

From: address@concealed [mailto:address@concealed] On Behalf Of Steve Rich
Sent: Tuesday, 13 October 2015 6:57 a.m.
To: address@concealed
Subject: [sympa-users] Footer unsubscribe link

 

Hi All,

 

At the request of our student users, we decided to append an unsubscribe footer to the bottom of every message for all lists that allowed for members to unsubscribe.  The implementation worked great with one exception.  The unsubscribe link we used contained was generated using the provided method from the docs in the form of [% wwsympa_url %]/auto_signoff/[% listname %]/[% user.escaped_email %].  Our testing indicated that it worked very well.  On the day we implemented it, we got a flurry of users reporting that they were being unsubscribed with no action on their behalf.  We started digging in to the logs and realized that the initial unsubscribe request (unauthenticated url above) was visited by one IP and then the followup authenticated url was visited by a different IP in the same block.  All of the IPs we checked were registered to Microsoft.

 

Our user email service is Office 365 and it turned out that Microsoft’s anti-spam/phish/malware protection was visiting the URL to ensure that it was safe before delivering the message.  We immediately rolled back the change and spent the better part of 2 days gathering stats on who was impacted and ensuring that users that were unintentionally unsubscribed were resubscribed to the list.  What made it worse were the forwarding and replying to of messages sent prior to rolling the change back.  

 

This got us thinking and we realized that the Microsoft is not the only company doing this.  A lot of email perimeter protection solutions (Proofpoint, Ironport, etc) will sandbox URLs prior to delivery to ensure that the URL is safe. I am currently working on a patch that requires a secondary action when visiting the unauthenticated and authenticated links (more than likely just clicking a button to confirm) and will send the patch to the list when I am done.  I just wanted to get this out there in case anyone else is thinking of implementing something like this for themselves.

 

Thanks,

Steve