Re: [mailop] "One-Click" List-Unsubscribe URIs

2016-06-10 Thread tobias.herkula 
On Thu, 9 Jun 2016 13:02:05 -0400
Al Iverson  wrote:

> On Thu, Jun 9, 2016 at 12:24 PM,   wrote:
> > On Thu, 9 Jun 2016 11:53:16 -0400
> > Al Iverson  wrote:
> >
> >> This also brings us back to the issue of what happens when security
> >> devices or services click the link, instead of the subscriber. In
> >> this scenario, it sounds like it would cause an unsubscribe that
> >> was not actually requested by the recipient. I think that is
> >> suboptimal.
> >
> > No it doesn't, the solution described in the document especially
> > solves this issue.
> 
> I think it is an insufficient solution that potentially allows a
> security device developer or service to build one click URLs just as
> easily as the ISP could. So it's got two things that I don't like.
> 1- You're requiring the ISP to identify and include a token in the URL
> - I don't think they should have to build something.
> 2- What's being built is just as easily added in by any security
> device who decides they know better than the subscriber and want to
> cause that unsubscribe.
> 
> Cheers,
> Al Iverson

With these arguments you can shoot down everything, SPF, DKIM, DMARC...
I'm not even trying to solve intended malicious behavior because it is
much more complex and I don't want to pick up a fight right now, I'm
simply not in the position to do that. The ORT session requirement or
question never wanted to solve this completely different issue at all.

Every other solution that came up in this discussion, run down to
possible pathes:

1# much more complex idea, that tries to solve a lot more than the
initial question asked for...

2# leaving the situation like it is right now without changing anything


Kind regards,

/ Tobias Herkula

--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany

Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499

Email:mailto:t.herk...@optivo.com
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula

Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618

optivo A company of Deutsche Post DHL Group


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

2016-06-09 Thread tobias.herkula 
On 9 Jun 2016 16:11:17 -
"John Levine"  wrote:

> >It's a public document and I welcome requests with updates...
> >https://github.com/Lockhead/oneclick/blob/master/draft-herkula-oneclick.txt
> 
> Hmmn.  One the one hand, I'm definitely in favor of making it as easy
> as possible for people to make the mail go away.
> 
> On the other hand, this particular proposal is a horrible misuse of
> both http GET and of the list-unsubscribe header.  The http specs are
> quite clear that GET is not supposed to change the state on the web
> server.  For that you use POST or PUT.  It is also a bad idea to try
> to redefine the List-Unsubscribe header which has meant the same thing
> for 18 years.
> 
> Fortunately, this is not hard to fix.  Let's invent a new header,
> list-unsubscribe-post, which one can use in conjunction with
> list-unsubscribe, e.g.
> 
>  List-Unsubcribe: 
>  List-Unsubscribe-Post: mailaddr=some...@receipient.de=0209023
> 
> This says to do a POST to the URL in the list-unsubscribe, with the
> fields in the list-unsubscribe-post as the data to the POST.  MUAs
> that don't understand the new field can still do a GET to the URL
> which will do whatever it does, probably show you a page with a
> confirmation button that does a POST.
> 
> This should be easy to implement, since I've never seen an http
> library that could do GET that can't also do POST, and this avoids
> both the semantic problem of GET, and the unintended unsubs by
> filterware that poke all the URLs just to see what will happen.
> 
> R's,
> John
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

I'm not a friend of "new" Headers and I can't really see why this
document will change any meaning of the standard, RFC2369 already
states:

"Each field typically contains a URL (usually mailto [RFC2368])
locating the relevant information or performing the command directly."

and

"The List-Unsubscribe field describes the command (preferably using
mail) to directly unsubscribe the user (removing them from the list)."

So it doesn't change any meaning of the standard, I'm aware of the fact
that there are entities out in the net that handle this differently but
the standard is pretty clear.

The document describes how to signal this functionality to make sure
the receiver knows that this link can be used as a "oneclick" and it
also hinders "dump" clients who simple GET every link to trigger the
action.

I'm sure we should argue about the GET vs. POST thing as this is for
sure very difficult to solve, if we stick by RFC you are totally right,
POST, PUT or even DELETE are the right verbs to use. I would rule out
PUT and DELETE because not every lib implements it. On the other side,
every tracking link in commercial mails changes STATE and they are
never requested by POST...


Kind regards,

/ Tobias Herkula

--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany

Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499

Email:mailto:t.herk...@optivo.com
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula

Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618

optivo A company of Deutsche Post DHL Group


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

2016-06-09 Thread tobias.herkula 
On Thu, 9 Jun 2016 11:53:16 -0400
Al Iverson  wrote:

> This also brings us back to the issue of what happens when security
> devices or services click the link, instead of the subscriber. In this
> scenario, it sounds like it would cause an unsubscribe that was not
> actually requested by the recipient. I think that is suboptimal.
> 
> Regards,
> Al Iverson
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

No it doesn't, the solution described in the document especially solves
this issue.


Kind regards,

/ Tobias Herkula

--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany

Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499

Email:mailto:t.herk...@optivo.com
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula

Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618

optivo A company of Deutsche Post DHL Group


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

2016-06-09 Thread tobias.herkula 
On Thu, 09 Jun 2016 14:30:29 +0200
Dave Warren  wrote:

> On 2016-06-09 12:23, David Hofstee wrote:
> > Same here, auto-unsubscribe presumed. The https is a nice addition 
> > that I will pass along. I hope that all implementations can handle 
> > https. Did people verify?
> >
> > I treat it nearly as strict as a feedbackloop. All streams (of my 
> > customer X) to the recipient will cease permanently. I cannot
> > expect Gmail (or others) to differentiate between specific
> > permissions that my customer uses and filter accordingly.
> 
> As a user, I like the idea of a HTTPS page that shows all lists to
> which I was subscribed, clearly indicates that I have been removed
> from all, but also has a one-more-click to resubscribe to specific
> lists if I desire.
> 
> A bit more complex, and I think the user expectation is that you'll
> be completely unsubscribed from all marketing drivel with one click,
> but in cases where there are clearly differentiated lists, it's nice
> to expose that to the user and give them a chance to reconsider.
> 

The view here is a little bit different, I don't really care what
happens in the body of the mails my customers send out, as long as they
don't violate our content policy or the law. So Links to preference
pages and all this stuff is fine there.

The document is more suited for functionality where the function should
be integrated into the MUA, like Googles "Easy Unsubscribe", in these
cases I would expect, that the platform provider doesn't want to show
external content and still needs a way to find out if the unsubscribe
worked.

#1 You could simply state as a platform provider that you expect that
   those links are "one-click" and give a penalty to senders who don't
   comply...

#2 You could use this pattern and be sure that the links are "one-click"

The second approach, in my opinion, is the easier way to implement this
feature, if you already settled on the idea to give your users a
unsubscribe button in your MUA.

Kind regards,

/ Tobias Herkula

--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany

Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499

Email:mailto:t.herk...@optivo.com
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula

Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618

optivo A company of Deutsche Post DHL Group


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] "One-Click" List-Unsubscribe URIs

2016-06-09 Thread tobias.herkula 
Hi List,

I'm working on a document about a topic that came out of an open
roundtable discussion at M³AAWG, it is more or less a way for mail
senders to signal that a URI in the List-Unsubscribe Header has
"One-Click" functionality and therefore can be triggered by backend
systems to provide MUA users a better way to unsubscribe from bulk
commercial mail that is reputable enough.

We as an ESP implemented it for our customers so if you are curious
about it, there is a chance that you already getting traffic with this
feature enabled.

I'm writing here because I'm looking for more input about it and if it
interesting enough for ISPs or MUA provider.

It's a public document and I welcome requests with updates...
https://github.com/Lockhead/oneclick/blob/master/draft-herkula-oneclick.txt

For people on the road a copy of the document is attached to this
mail...


Kind regards,

/ Tobias Herkula

--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany

Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499

Email:mailto:t.herk...@optivo.com
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula

Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618

optivo A company of Deutsche Post DHL Group
INFORMATIONAL Tobias Herkula
draft-herkula-oneclick.txt   optivo GmbH
   June 2016


   Signaling "One-Click" functionality for HTTPS URIs in email headers

Status of this Memo

   This document is not an Internet Standards Track specification; it is
   for informational purposes and requests discussion and suggestions
   for improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) Tobias Herkula (2016).  All rights reserved.

Abstract

   This document describes a simplified method for signaling "One-Click"
   functionality for HTTPS URIs as they appear in email headers.  The
   need for this arises out of the fact, that third-party entities
   involved in the processing of emails sometimes unintendedly trigger
   actions that are subject to the user and shall not be triggered
   automatically without an user's intent.

1.  Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   a.  "One-Click":  In the context of this document, describes an HTTPS
   URI that directly triggers a change in a system that shall only
   be applied if the request to that HTTPS URI is done with an
   user's intent.

   b.  "Organizational Domain":  Is to be interpreted as described in
   [RFC7489#section-3]

   c.  "Domain Alignment":  In the context of this document, means that
   two domains share the same organizational domain.

   d.  "signal-constant": fixed string "=One-Click"

2.  Introduction

   An email header can contain HTTPS URIs for extended functionality,
   for example List-Headers [RFC2369].  In case of the List-Unsubscribe
   Header the HTTPS URI is mandated to unsubscribe the recipient of the
   email directly from the list.  This requirement is often not
   implemented because anti-spam solutions request all found external
   resources, this is considered unintended malicious behavior. In
   consequence senders implement landing pages asking to confirm the
   unsubscribe request.  This specification tries to solve one part of
   this, as it proposes a pattern to detect "One-Click" functionality.
   It defines a specific format for the fragment part of a HTTPS URI and
   a specific transformation for the receiver. A request to the
   transformed HTTPS URI from somebody who adheres to this specification
   can be distinguished from other requests and therefore handled
   independently.

3.  High-Level Goals

   o  Allow email senders to signal "One-Click" functionality for
  specific HTTPS URIs used in email headers.

   o  Allow MUA owners to implement independent user interface features
  for a better user experience.

   o  Allow MUA users to trigger intended actions in a familiar
  environment.

4.  Out of Scope

   This proposal does not solve problems associated with intended
   malicious behavior by users or robots.

5.  Implementation

5.1  Sender

   A sending entity which is responsible for the content of an email,
   that wishes to add an actionable HTTPS URI in the header of an email,
   shall add the name of the Header followed by signal-constant, as the
   URI fragment. The sending entity also needs to provide the infrastructure
   to handle GET and or POST requests to this URI in an appropriate volume.

   The "One-Click" action triggered by such URIs must complete in an appropriate
   timeframe

Re: [mailop] Gmail throttling our office mail server

2016-06-06 Thread tobias.herkula 
I normally don't handle the office infrastructure and wasn't even aware
of this until this thing happened. We disabled all external forwards
and only allow pop3 fetch now if somebody wants or needs to use his own
mailbox. Thx for the advice.

On 3 Jun 2016 17:14:46 -
"John Levine"  wrote:

> >relay setting for an external user who is hosting his mail on Google
> >apps and besides simple spam filtering we relayed everything.
> 
> You don't want to do that.  The approach I've found that works least
> badly is to do stringent spam filtering (spamassassin with a threshold
> of about 4), forward the stuff that passes, and put the rest in a
> local mailbox that is polled by POP3 from the Google account.  That's
> easy to set up, and he'll get all of his mail eventually.  If Google
> puts stuff in the spam folder that he wants, not your problem.
> 
> R's,
> John
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Kind regards,

/ Tobias Herkula

--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany

Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499

Email:mailto:t.herk...@optivo.com
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula

Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618

optivo A company of Deutsche Post DHL Group


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail throttling our office mail server

2016-06-06 Thread tobias.herkula 
Thx, the problem was solved on friday evening.

On Fri, 3 Jun 2016 11:50:51 -0700
Brandon Long via mailop  wrote:

> This throttle seems excessive, even though it's only temporary.  I've
> filed a bug against our spam team to take a look.
> 
> Brandon
> 
> On Fri, Jun 3, 2016 at 4:30 AM,  wrote:
> 
> > Hi,
> >
> > I'm currently seeing only this error
> >
> > 421-4.7.0 Our system has detected an unusual rate of unsolicited
> > mail originating from your IP address. To protect our users from
> > spam, mail sent from your IP address has been temporarily rate
> > limited. Please visit https://support.google.com/mail/answer/81126
> > to review our Bulk E mail Senders Guidelines. vx5si6861009wjc.33 -
> > gsmtp
> >
> > for all Mails going from 213.61.69.122 (office.optivo.de) to any
> > Google Apps Domain or Gmail Recipient. It's not much traffic (2k
> > mails in a week). I'm pretty sure I identified the reason for that,
> > we had an relay setting for an external user who is hosting his
> > mail on Google apps and besides simple spam filtering we relayed
> > everything.
> >
> > I really hope that this is the only reason, because on this host
> > 99% of the traffic is one2one communication and therefore should
> > not trigger any bulk filter...
> >
> > Would be nice if somebody who is able to look into this, could give
> > me a short catchup if we have any other issues on this host...
> >
> > Kind regards,
> >
> > / Tobias Herkula
> >
> > --
> > optivo GmbH
> > Head of Deliverability & Abuse Management
> > Wallstraße 16
> > 10179 Berlin
> > Germany
> >
> > Tel: +49(0)30-768078-129
> > Fax: +49(0)30-768078-499
> >
> > Email:mailto:t.herk...@optivo.com
> > Website:  http://www.optivo.com
> > Linkedin: http://www.linkedin.com/in/tobiasherkula
> >
> > Commercial register: HRB 88738 District Court Berlin-Charlottenburg
> > Executive board: Dr. Rainer Brosch, Thomas Diezmann
> > Vat reg. no.: DE813696618
> >
> > optivo A company of Deutsche Post DHL Group
> >
> >
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> >




Kind regards,

/ Tobias Herkula

--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany

Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499

Email:mailto:t.herk...@optivo.com
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula

Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618

optivo A company of Deutsche Post DHL Group


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Gmail throttling our office mail server

2016-06-03 Thread tobias.herkula 
Hi,

I'm currently seeing only this error

421-4.7.0 Our system has detected an unusual rate of unsolicited mail
originating from your IP address. To protect our users from spam, mail
sent from your IP address has been temporarily rate limited. Please
visit https://support.google.com/mail/answer/81126 to review our Bulk E
mail Senders Guidelines. vx5si6861009wjc.33 - gsmtp

for all Mails going from 213.61.69.122 (office.optivo.de) to any Google
Apps Domain or Gmail Recipient. It's not much traffic (2k mails in a
week). I'm pretty sure I identified the reason for that, we had an
relay setting for an external user who is hosting his mail on Google
apps and besides simple spam filtering we relayed everything.

I really hope that this is the only reason, because on this host 99% of
the traffic is one2one communication and therefore should not trigger
any bulk filter...

Would be nice if somebody who is able to look into this, could give me
a short catchup if we have any other issues on this host...

Kind regards,

/ Tobias Herkula

--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany

Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499

Email:mailto:t.herk...@optivo.com
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula

Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618

optivo A company of Deutsche Post DHL Group


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] S/MIME Signature alignment

2016-02-10 Thread tobias.herkula 
I'm currently trying to wrap my head around this S/MIME signature
thing, is there any best practices document besides the couple of RFCs
that says something about the alignment between the used cert and the
5321From or 5322From? Like for SPF that must align to 5321From and DKIM
that must align to 5322From...

Kind regards,

/ Tobias Herkula

--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany

Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499

Email:mailto:t.herk...@optivo.com
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula

Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618

optivo A company of Deutsche Post DHL Group


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop