Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists

"Murray S. Kucherawy" <superuser@gmail.com> Mon, 14 April 2014 17:53 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9181D1A0208 for <ietf@ietfa.amsl.com>; Mon, 14 Apr 2014 10:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.301
X-Spam-Level: *
X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFp5o6JBnekt for <ietf@ietfa.amsl.com>; Mon, 14 Apr 2014 10:53:46 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1AF1A01FC for <ietf@ietf.org>; Mon, 14 Apr 2014 10:53:45 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id cc10so4453728wib.14 for <ietf@ietf.org>; Mon, 14 Apr 2014 10:53:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ev1CngUV9hdhEOR2e3tkJljhBUvl5nRToY4eQg0G3xU=; b=AynKSd5qOcUimTKCOaizYBrJkeYD1KvknOzmRqth8GehBsK7HcZeiQ2qRQrn0ERA6t r04o9N+40myq6xyo+wvjN1TCQrQM6nhiJQzauHdUvP26WdyYnktbOZIpvN/ND4xRlaMs x4oe29XJxj/G6+fSdk1H4vKTBTv6foGg9JvfzTcJ7q6aRjFTP6nq3l4aQNANZq3T/S/+ AoB3vVS8dIpF/7ZhI9nOJu1Mvi85/3+DBQWe4wLrEXbRZBICCVACfb8eJuErX8j+awJ5 /s5muict2cIJr4jtaUFF5YBaUxgp34zTaARcI1t1z3SgRAJYVCkCgdBRmuiI7U+1OuZc rSEg==
MIME-Version: 1.0
X-Received: by 10.180.84.129 with SMTP id z1mr10523391wiy.8.1397498022765; Mon, 14 Apr 2014 10:53:42 -0700 (PDT)
Received: by 10.180.90.140 with HTTP; Mon, 14 Apr 2014 10:53:42 -0700 (PDT)
In-Reply-To: <01P6L9JZF5SC00004W@mauve.mrochek.com>
References: <53499A5E.9020805@meetinghouse.net> <5349A261.9040500@dcrocker.net> <5349AE35.2000908@meetinghouse.net> <5349BCDA.7080701@gmail.com> <01P6L9JZF5SC00004W@mauve.mrochek.com>
Date: Mon, 14 Apr 2014 10:53:42 -0700
Message-ID: <CAL0qLwZr=wVX6eD+yGVOaxkSy5fJbuAErTshOG+2BywUvkDfAA@mail.gmail.com>
Subject: Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: "ned+ietf@mauve.mrochek.com" <ned+ietf@mauve.mrochek.com>
Content-Type: multipart/alternative; boundary=f46d043bdec038aa7304f7045d81
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/BHfQd2yn_x0fukFawC7gwKggsb8
Cc: ietf <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Apr 2014 17:53:47 -0000

On Sat, Apr 12, 2014 at 4:35 PM, <ned+ietf@mauve.mrochek.com> wrote:

> The underlying technical issue is that the two technologies DMARC is built
> on -
> DKIM and SPF - both attach additional/restrictive semantics to
> longstanding mail
> system fields. (Broadly speaking, From: for DKIM and MAIL FROM for SPF.)
>

Something's amiss here.  What new semantics does DKIM attach to From:?  As
far as I know, it only requires that the field be signed.  It doesn't
require that it be interpreted in a particular way or that it contain any
particular value.


> It goes on to discuss the use of p=reject with domains that only send
> transactional. AFAICT there is no discussion of when *not* to use
> p=reject, and
> why. Nor, for that matter is there substantive discussion of mailing_list,
> and why it's not a general solution to the problems caused by p=reject.
>

Yes, that's useful advice for a future revision.


> Like it or not, the IETF published a draft that defines certain mechanisms
> which, if used improperly by a large provider, cause serious problems for a
> large number of people. The text describing the consequences of the use of
> those mechansisms in the drafts is, IMO, entirely inadequate.
>

It's the same document that was posted on other web sites for some time,
and was in use by a number of operators (including Yahoo) long before it
went into the datatracker.

As it's only a draft, there's ample opportunity to make such improvements.

Also: By "the IETF published a draft", are you talking about an RFC, or the
DMARC base draft?  It seems extreme to lay blame on the IETF in general
merely for having an open mechanism by which to post a draft for all to see
and discuss.  A "Request For Comment", as it were.  Are you suggesting that
process should be closed or moderated somehow?


> And it's not like we didn't know. As others have pointed out, this issue
> existed in the earlier ADSP proposal. It was given insufficient attention
> there
> as well.
>

As with any draft, its content is only as good as its contributions and the
reviews it got.


> Of course the IETF can fall back on the usual excuses, including, but not
> limited to:
>
>     Yahoo, of all ISPs, should have known better
>     We don't tell people what to do
>     It was just a draft
>     It was never intended to be a standard
>     We're not the Internet Protocol Police
>     etc.
>
> I'm sorry, but this time none of these dogs are hunting for me. An
> attractive
> nuisance is an attractive nuisance, and this is what the IETF has, albeit
> with
> the best of intentions, managed to create.
>

I would add to this that, by its ultimate inaction in the face of a
protracted period of abuse and attempts by participants to solve that
problem within its procedures, the IETF has abdicated any authority it may
have had.

The real question we should be discussing is what options the IETF has to
> try
> and address this.
>

I certainly agree with that.

-MSK