--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.
> 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