Re: DMARC and yahoo

[Douglas Otis <[e-mail]>]

On Apr 20, 2014, at 11:49 PM, John C Klensin <[e-mail]> wrote:

> 
> 
> --On Monday, 21 April, 2014 08:26 +1200 Brian E Carpenter
> <[e-mail]> wrote:
> 
>> Unfortunately they can switch themselves back to normal mode
>> too. Digest mode is user-settable, and is very annoying because
>> it munges the Subject header. What's really needed is a
>> DMARC-safe mode (per subscriber) that optionally rewrites the
>> From.
> 
> Brian, I think there are several ways to look at this and that
> there are some largely separable issues.  One of them, perhaps
> unreasonable and perhaps not, is that DMARC was developed by a
> collection of organizations who have a shared vision of how
> email should work, what is important, and what isn't.  Yahoo is
> a supporter/participant in that group, as are several people
> with sufficient IETF history and leadership roles to be
> knowledgeable about how to facilitate getting a document through
> the system.  
> 
> I think that raises some issues for the IETF and RFC Editor
> about how specifications developed entirely in other bodies --
> traditionally, a category known as "specifications developed
> elsewhere and republished for the convenience of the Internet
> community" -- should be handled.   While it no longer applies in
> the DMARC case, there are also some issues associated with
> moving stable specifications developed elsewhere through the
> IETF Standards Track (whether one calls that "fast track",
> "rubber stamp", or something more complementary).   Pete has
> mentioned that the IETF is looking at some of the issues
> involved; I hope the ISE, and RFC Editor Function more
> generally, are too.
> 
> As far as the mailman hack is concerned, I think there are two
> different relevant audiences/ affected communities:
> 
> (i) Receivers who happen to have addresses associated with DMARC
> supporters, such as Yahoo, that have adopted a
> highly-restrictive policy.  Forcing them into Digest mode, and
> warning them that, if they turn it off, they are unlikely to
> receive any more list mail and will likely be dropped from the
> list seems to be to be appropriate.  It was with that audience
> in mind that I claimed that Jeffrey's action was elegant.  I
> still think so, YMMD.
> 
> (ii) Senders who have chosen to send messages from mail
> providers who have adopted restrictive, DMARC-based, policies.
> From my point of view, those providers have made a decision that
> they aren't interested in having their mail users post messages
> to mailing lists.  If a mail providers wants to effectively
> restrict the types of mail their users can send, I think we have
> to defend their right to do that.  It is also reasonable to hope
> that users who think those services are useful will go elsewhere
> and for mailing list managers to protect themselves by denying
> posting privileges to such users or remove them from lists.   I
> think it would be a great deal more ethical and professional if
> those providers took responsibility for that decision with an
> explicit announcement to their users, but that is really not an
> IETF problem.  
> 
> As to your "DMARC-safe mode", I'm inclined to assume that Yahoo
> knew exactly what would happen if they made this move.  To
> believe otherwise raises significant questions about the quality
> of development and review of the DMARC spec and hence whether
> the IETF or ISE should publish it in any form, at least in the
> absence of a rebuttal or public review and commentary.  The
> belief that it was intentional is also reinforced by the
> observation that this problem has now been known for quite a
> while (in Internet time) and Yahoo has not chosen to modify
> their preferences to some other option.  Given that, I think we
> should be very cautious about recommending a technique to
> subvert their intentions: such actions have too much history of
> leading to counter-actions that have even worse effects.

Dear John,

Well put.

May I say the TPA remedy is under the control of sending domains without impacting mailing list operation, assuming third-party SPF or DKIM or whatever verification benefits from a domain specific authorization.

Employing SRS or vouching like schemes removes control from senders since neither DKIM nor SPF capture intended recipients.  As such, this may have trouble gaining cooperation or retaining delivery integrity with tokens and return-paths arranged like an unmanageable collection of Matryoshka dolls.  TPA can be quickly implemented once a sender expresses a desire to have all needed exceptions under their control.

Regards,
Douglas Otis