Dedicated "unsubscribe" page to unsubscribe without login

[DReffects2]

Hey Guys,

so local law dictates that users need to be able to unsubscribe from newsletters with a simple process. Is there a feature within IPS that allows just that?

I have a community with over two decades of users, many of them recieve newsletters (~1-2 times a year) but don't even know their account password so they cannot unsubscribe... 

Thanks 🙂

[bfarber]

There should be an unsubscribe link at the bottom of every bulk mail. The link should still work as I recall even if the user is not logged in (the email address and a special key is included in the unsubscribe link for this purpose).

[DReffects2]

36 minutes ago, bfarber said:

There should be an unsubscribe link at the bottom of every bulk mail. The link should still work as I recall even if the user is not logged in (the email address and a special key is included in the unsubscribe link for this purpose).

I know but I currently have a situation where this is not applicable:

Spam-Traps are being created for mailboxes that have been cancelled by users and are located either with the email providers themselves (for example outlook.com) or by anti spam lists like Cloudmark.

If you send out bulk mails frequently you can take care of bounces and unsubscribe mailboxes that do not exist anymore. But if you only send out community mails lets say every 8-10 months you run into a serious problem:

• Bulk Mail sent on the 1st of january
• User communityfan@t-online.de cancels his mailaccount on january the 2nd
• Mailproviders and/or Spamlist like Cloudmark convert this mailbox into a spamtrap after 6 months
• You send your next community mail on October the 1st
• Spamtrap is being triggered

I had this happen twice within the last few months (with a t-online mailbox and with a mailbox where the isp uses cloudmark) and there is no way to unsubscribe the user since you do not know what address is actually a spam trap. 

Providers like t-online and cloudmark do NOT tell you the affected account since they want to protect their spam traps, plus it would be a violation of data privacy laws. Also, cloudmark only has the header info on file, so they cannot even click the unsubscribe link or log in.

I had a similar situation with a phplist powered newsletter system and t-online was kind enough to unsubscribe with the dedicated unsubscribe page after I explained the situation. I cannot do that with my community since there's no dedicated unsubscribe page. (which european law actually wants you to have...)

please look at this response from cloudmark:

I CAN NOT use Feed Back Loops since they are prohibited within the entire european union.
(See https://postmaster.t-online.de/#t4.10 for example)

Can you provide a solution for this predicament? Thanks!

[bfarber]

If you have no idea what email addresses are bad, what good is a dedicated unsubscribe page? It sounds like two fairly unrelated concerns. You indicated that the providers only pull in the header information from the email, so even if there was a standalone unsubscribe page and the link was included in the email, it wouldn't do you any good for the concern you're facing here?

[DReffects2]

6 hours ago, bfarber said:

If you have no idea what email addresses are bad, what good is a dedicated unsubscribe page? It sounds like two fairly unrelated concerns. You indicated that the providers only pull in the header information from the email, so even if there was a standalone unsubscribe page and the link was included in the email, it wouldn't do you any good for the concern you're facing here?

As I have mentioned above, providers do unsubscribe the spam trap by hand if you can provide an unsubscribe page since they do not have to disclose the information this way, so this would help a great deal. ( A simple page with "Please enter the e-mail address you'd like to unsubscribe")

The Certified Sender Alliance recommends to implement https://tools.ietf.org/html/rfc8058 into the header of the e-mail for just that reason. 

   Header in Email

   List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
   List-Unsubscribe-Post: List-Unsubscribe=One-Click

   Resulting POST request

   POST /unsubscribe/opaquepart HTTP/1.1
   Host: example.com
   Content-Type: application/x-www-form-urlencoded
   Content-Length: 26

   List-Unsubscribe=One-Click

This way providers and anti-spam providers like cloudflare can remove their spam traps from lists without the actual content of each e-mail. (and if you talk to them)

[bfarber]

We do send a List-Unsubscribe header in every email already which contains an unsubscribe link, and it points to the dedicated unsubscribe link for that email. So - then you're covered?

[DReffects2]

26 minutes ago, bfarber said:

We do send a List-Unsubscribe header in every email already which contains an unsubscribe link, and it points to the dedicated unsubscribe link for that email. So - then you're covered?

uhm... that's not the case for my community mails. Is this overridden by custom templates?

I only see these headers:

Return-Path: <noreply@XXXX.de>
X-Original-To: d.raebiger@XXX.de
Delivered-To: d.raebiger@XXX.de
Received: from www.XXXX.de (XXX.XXX.pro [85.XXXX.XXXX.81])
	by XX.XXXX.XXXX (Postfix) with ESMTPA id DCCF464406CD
	for <d.raebiger@XXX.de>; Mon, 16 Sep 2019 02:35:25 +0200 (CEST)
MIME-Version: 1.0
To: d.XXXXX@XXXXX.de
From: =?UTF-8?B?U2NpZmluZXdzLkRF?= <noreply@XXX.de>
Subject: =?UTF-8?B?R2FzdCBoYXQgZWluZSBOZXdzbWXXXXXXN0ZWxsdCwgd2VsY2hlcyBnZW5laG1pZ3VuZ3NwZmxpY2h0aWcgaXN0?=
Date: Mon, 16 Sep 2019 00:35:25 +0000
Auto-Submitted: auto-generated
Precedence: list
Content-Type: multipart/alternative;
 boundary="--==_mimepart_282da6a66bcd1cbc6a983fb982f99bbf"; charset=UTF-8
Content-Transfer-Encoding: 8bit
Message-Id: <20190916003525.DCCF464406CD@XXXX.XXXX.XXX>
X-PPP-Message-ID: <20190916003526.13149.85940@XXXX.XXX.XXXX>
X-PPP-Vhost: XXXX.de
X-EsetId: 37303XXX305568627266

 

[bfarber]

Thanks - we used to set this header, but it looks like it was removed when the email handler was refactored back around 4.2.0. I'll see if it can be re-added.

[DReffects2]

1 minute ago, bfarber said:

Thanks - we used to set this header, but it looks like it was removed when the email handler was refactored back around 4.2.0. I'll see if it can be re-added.

Ah 🙂 Superb!

Please make sure to include it also with ALL mails sent by the community like the notification emails etc. 🙂

Stupid EU law, sorry 😞