Re: [marf] Adrian Farrel's No Objection on draft-ietf-marf-as-15: (with COMMENT)

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 25 April 2012 20:32 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: marf@ietfa.amsl.com
Delivered-To: marf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E21E11E8083; Wed, 25 Apr 2012 13:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.521
X-Spam-Level:
X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rx34DNRdD1C; Wed, 25 Apr 2012 13:32:06 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id C1CF421E800F; Wed, 25 Apr 2012 13:32:05 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3PKVphF009626; Wed, 25 Apr 2012 21:31:51 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3PKVnIk009620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Apr 2012 21:31:50 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Murray S. Kucherawy'" <msk@cloudmark.com>, 'The IESG' <iesg@ietf.org>
References: <20120425170640.27848.77721.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E00392810297C@exch-mbx901.corp.cloudmark.com>
In-Reply-To: <9452079D1A51524AA5749AD23E00392810297C@exch-mbx901.corp.cloudmark.com>
Date: Wed, 25 Apr 2012 21:31:48 +0100
Message-ID: <073501cd2322$71120900$53361b00$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQL0KC9i4/IYaruXuTwYGVqhSUKftQGa1sZUlFEbsEA=
Content-Language: en-gb
X-Mailman-Approved-At: Wed, 25 Apr 2012 13:32:39 -0700
Cc: draft-ietf-marf-as@tools.ietf.org, marf-chairs@tools.ietf.org, marf@ietf.org
Subject: Re: [marf] Adrian Farrel's No Objection on draft-ietf-marf-as-15: (with COMMENT)
X-BeenThere: marf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Message Abuse Report Format working group discussion list <marf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/marf>, <mailto:marf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/marf>
List-Post: <mailto:marf@ietf.org>
List-Help: <mailto:marf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/marf>, <mailto:marf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 20:32:06 -0000

Hi Murray,

Thanks for this...

> > Forgive me, but doesn't section 8.2 say that forged abuse reports
> > constitue a real problem and the two mechanisms available to protect
> > against them may result in genuine abuse reports being discarded?
> 
> Yes to the first point.  The second point is true of all email, not just abuse reports;
> if the signer's infrastructure is causing signatures to break, there's no reason to
> trust the reports even though they bear some kind of signature.  The same goes
> for, say, a message from your bank that's signed but the signature fails to
> validate.
> 
> > Is the message here "chosse which you think might be the least worse
> > problem" or is it "you should use DKIM and SPF, but be aware that you
> > may lose some genuine reports"?
> 
> It's "You should use DKIM and/or SPF, but make sure they're working properly if
> you want to reap the benefits."
> 
> > I would have liked some clarification as to which message is being
> > sent.
> 
> That section is only talking about reports.  Which part is unclear?

Simply (to my reading - which you may ignore if you feel I am not reading clearly) that the thought you captured above is not clear.

I read a rather despairing statement that since DKIM and SPF might not be working it is a toss-up whether you have reports being discarded because the signature fails or reports being spoofed.

If this is "state of the art" for email systems then maybe there is nothing else to say.

It struck me, however, that reports are going to be consumed by automatic systems. If I get an email where the signature fails, I can perform all sorts of human verification of the email and make a judgement call on the validity of the email. A software system processing reports is less flexible and so more exposed.

Perhaps the clarity that is needed is the strong hint that "Therefore the use of DKIM and/or SPF is RECOMMENDED and it is important to ensure that the security infrastructure is working properly."

Cheers,
Adrian