On Mon, 12 Sep 2016 23:15:52 -0400 John C Klensin <klensin@xxxxxxx> wrote: > --On Monday, September 12, 2016 21:45 -0400 "John R. Levine" > <johnl@xxxxxxxx> wrote: > >>> important protection against accidental (but, IMO, badly >>> designed) or malicious bad behavior. So this specification >>> proposed a way to bypass those safeguards and protection? >> >> No, of course not. The unsubscribe links in the mail this >> will affect are invariably unique to the message's recipient >> with a hard to forge hash of some sort. So if you have the >> message, you are the subscriber or the subscriber gave the >> message to you. > > But that doesn't show up in your the examples and, as far as I > can tell from quick reading, there is nothing in the text that > says "the unsubscribe links need to contain a hard to forge hash > or this would be a really bad idea" or something equivalent. > My guess is that this would be harmless at worst if the security > and operational issues were spelled out, but they aren't. > > AFAICT, such a hash would be a better solution than the weaker > one I was contemplating with DKIM, so there may be just a > documentation problem rather than a technical one. In section 5.1 it only forces the sending side to implement it in a way, so that they can identify the recipient by only the information they but into the two Header fields. We for example use something like this: List-Unsubscribe: <http://example.com/go/13/1UJBVSN4-1UAMMHU8-1UHCJOWL-122U7IX.html> List-Unsubscribe-Post: List-Unsubscribe=One-Click This requirement does not stretches to the receiving entity. The purpose of the document is to standardize the way to inform the receiving entity that the HTTPS URI provided in the List-Unsubscribe Header offers one-click functionality. More requirements are not needed and would to a certain point even diminish interop, as almost every single bulk-mail provider and mailinglist manager have their own beliefs in how to handle their unsubscription processes... >> I've talked at some length to the people at Gmail who plan to >> implement this, and they've clearly dealt with more mail >> forgery than any of us. > > Ah. That may suggest the disconnect we are having lies > somewhere other than in what I assumed. This document appears > to have been written for Standards Track and the Last Call is > for publishing it as a Proposed Standard. That implies at least > a plausible assumption or realistic hope that it will be > implemented and deployed by multiple independent parties. For > that purpose, it just isn't complete and doesn't contain enough > information, with that issue about hashes as one example, > perhaps among many. > > If you want to see this as a Proposed Standard, then I think > there needs to be enough information, clearly spelled out, to > let people implement it in a way that is both interoperable and > safe. > > The other possibility is that this is a Gmail idea or plan and > the real purpose of publication is to register a new header > field and tell MUA authors what they should do if they get some > fields Gmail is about to start producing. That would make a > perfectly sensible Informational document that could be > descriptive rather than normative about what they sender/ > mailing list software does and only use more or less the current > text to specify what the recipient/ would-be unsubscriber does. > You could probably even submit it through the Independent Stream > and try to convince the ISE to accept Section 4 or a variation > on it -- I believe that section and the narrowly-focused > Security Considerations one that results violates the intent and > requirements of BCP 72 that apply, AFAICT, to all IETF Stream > technical specifications. > > john > If an attacker has access to these Headers he also has access to the body of the mail, so from an security standpoint in makes no difference, that is the reason this document does not try to fix this vector, it is out of scope. The intention for this came from an Open Round Table discussion at M³AAWG from last year and a wide acceptance in the group of mail handling entities at M³AAWG is the reason this document was brought up to the IETF. There are at least 2 major ISPs, 3 E-Mail Service Providers and 2 other related parties already working on the implementation. 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.herkula@xxxxxxxxxx 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