Subject: [Asrg] Triple opt-in, was MLMs and signatures again

From: Alessandro Vesely <[email-masked]>
Date: Fri, 27 May 2011 20:17:02 +0200

On 27/May/11 18:29, John R. Levine wrote:
>>>> 2) do we need a mechanism to alert the receiving MTA that you have
>>>> subscribed to a mailing list, and all messages should pass through?
>>
>> Yes, desperately.
>>
>>> Certainly a possible feature, but it seems like it won't scale very well.
>>
>> Why not?
> 
> If I were a spammer, I would tell the victim's MTA that the victim 
> subscribed, then send the spam.

Yes, but then the MTA would then know how to treat the corresponding
victim's complaint.

> These days most subscriptions are entered on a web page, and if you're 
> lucky the mailer will send a confirmation message with a URL that sends 
> the subscriber back to the web page.  Where's the MTA going to get the 
> subscriber info?

An http url could be advertised on the MX's EHLO reply.  That's a page
on the users' server, where they can confirm subscriptions along with
their credentials.  MLMs get digitally signed confirmations of COI.

Ways to accept non-interactive subscription notifications are also
necessary.  I agree they are somewhat more challenging.

For MLMs that present DKIM-signed List-* header fields, subscriptions
might be assumed, and tracked unilaterally that way.  But unsubscribe
attempts seem to be more difficult to do, in this case.

> The challenges in designing a protocol that neither makes 
> unreasonable demands on users and MUAs nor is easily spoofed by
> hostile mailers seem insurmountable to me.

MUAs wouldn't be much affected, except for allowing TiS buttons.

Users would gain uniform subscribe/unsubscribe pages.

> If you're planning to keep a reputation database of mailers who
> send credible subscription announcements, why not just whitelist
> their mail?

The ability to maintain such database would be improved.

> Since as far as I know nobody does this, it's a resarch topic, so I've 
> directed replies to the ASRG.  See you there.

Here I am.  I've kept a CC to DKIM list, to be removed in followups.

It is not the first time I bring up this idea on the ASRG.  It
addresses newsletters more than discussion lists, because of the way
subscriptions work.  In Europe, the resulting protocol could help
providing proofs of consent, which many European newsletters handle as
a checkbox on _manually_ signed forms.  Indeed, I'd consider it an
implementation of the Data Protection Directive.

---

From: David Nicol <[email-masked]>
Date: Fri, 27 May 2011 17:20:26 -0500

> > subscribed, then send the spam.

But you couldn't do that, as the spammer, because such a feature belongs in
the per-user-database parts of the hypothetical future extended/hybrid
MTA/MDA with the feature. Proper debate on this feature should be about how
to present the feature to the end-user, not on an insecure external wire
protocol. Such as, how much reputation does a mailing list need before it
gets to skip the "New mailing list subscription? Click here to approve!
Futur-eMail, relaxing your eyeballs since 2015" kind of end-user approval
step.  Current mailing list headers provide plenty of information to
automate that decision on the receiving side, and have for over a decade,
especially when listserv IP addresses are included in the data.

In my opinion, trying to automate confirmation of opting in with some kind
of mailing list extension protocol proposal is something of a non-starter
for other reasons too, primarily the installed base problem. Unless you
really really want to disenfranchise independent mailing lists because
you're a consortium of Big Mailing List Providers and want to make the few
remaining independent mailing lists that haven't already migrated to, for
instance, google groups, convert.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 28 May 2011 14:28:42 +0200

On 28/May/11 00:20, David Nicol wrote:
> In my opinion, trying to automate confirmation of opting in with some
> kind of mailing list extension protocol proposal is something of a
> non-starter for other reasons too, primarily the installed base
> problem.

Yes, there is too much inertia.  However, complying with EU privacy
directives might confer some potential to such kind of protocol.