Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)

mrex@sap.com (Martin Rex) Thu, 17 July 2014 19:57 UTC

Return-Path: <mrex@sap.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 76FAF1A0360 for <ietf@ietfa.amsl.com>; Thu, 17 Jul 2014 12:57:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 vjiIR3KObWPI for <ietf@ietfa.amsl.com>; Thu, 17 Jul 2014 12:57:15 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703FB1A00D6 for <ietf@ietf.org>; Thu, 17 Jul 2014 12:57:15 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s6HJvCvK004375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Jul 2014 21:57:12 +0200 (MEST)
Subject: Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)
In-Reply-To: <6C10A695-8F29-4D94-8CF5-FAA0E975A33E@gmail.com>
To: Douglas Otis <doug.mtview@gmail.com>
Date: Thu, 17 Jul 2014 21:57:12 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140717195712.11D7B1ADAE@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/Phhoys4DVp3o93JPnVYAbt4xXhw
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Thu, 17 Jul 2014 19:57:18 -0000

Douglas Otis wrote:
> 
> Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
>> 
>> This is a solved problem, the "Rfc822.Sender" field should have
>> from the outset trumped the "Rfc822.From" field when determining
>> message origin, and the DMARC policy should be that of the "Sender"
>> domain.  Some MUAs already expose "Sender != From" by displaying
>> "From <sender> on behalf of <author>".  This needs to become standard
>> MUA behaviour.

Only the most clueless MUA programmers got this wrong in the first place.
>From a probability standpoint, now counting on those to (a) take the
blame and (b) get it right this time may be somewhat optimistic.


The main problem that I have is DMARC, is that the approach is
technically and morally wrong, and legally prohibited (=criminal)
in properly civilized countries.


A better approach would be for the final MTA to perform DMARC (DNS) lookups
and prepend the results as new, standardized header lines to the message,
and have the MUA process these new header lines and **suppress** displaying
of the "rfc5322-From:" for messages that are supposed to verify but don't.

And DMARC reporting needs to be killed.


> 
> You are right, but this provides a domain not always seen by recipients.
> Only the From header field is surely displayed.  

So you at least agree that it is the broken MUAs that cause the problem.


When the details about the OpenSSL heartbeat vulnerability was published,
would it have been better to force all ISPs to detect and tear down
TCP connections that "exploit" the weakness, or to fix the broken software?


-Martin