Re: (DMARC) We've been here before, was Why mailing lists

Douglas Otis <> Thu, 17 April 2014 19:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 608981A0193 for <>; Thu, 17 Apr 2014 12:20:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EWcDIJoobpAk for <>; Thu, 17 Apr 2014 12:20:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::22d]) by (Postfix) with ESMTP id 1DF921A00FB for <>; Thu, 17 Apr 2014 12:20:45 -0700 (PDT)
Received: by with SMTP id kl14so689912pab.32 for <>; Thu, 17 Apr 2014 12:20:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=01Q9A9O8QxTZu9qBeXWUADUtRmX9JFVyP+EiVvzmcWo=; b=Jz5CqP6xSNiEuZ7fDA5ZdnEm2ZA+yKtQOe+FmXgFfMxN7T6ScXnJ56l/g5kSGciFyX oQDuIwXNEiboRxnV844GvVI5TH9X3aBMMQcJMPz/lttVV4gPyqdRERsZZw2B4zMSKPxy t/vlXLWXu4cX0lAYPt2o5ahkAyQPrpFWsGU2szP31Yg+c1sbZgtZdusa6kXfTwu7WuqU k2mRhKWq12jEuIG8mdK8eyucr37474fO8AOGxzfIjYFM2kiwXXkYSD9lWH7MjYa5rPPi 5P6TGWz2ZKRRtcHbo/hucqGXDkBHK1wa8rwSTlL/FS+z+1rG5xcnIYmNx6m55Vl2qBa9 gtbw==
X-Received: by with SMTP id vs9mr17760345pbc.84.1397762441501; Thu, 17 Apr 2014 12:20:41 -0700 (PDT)
Received: from ?IPv6:2601:9:1b80:1046:d5d2:6efc:7b10:3c95? ([2601:9:1b80:1046:d5d2:6efc:7b10:3c95]) by with ESMTPSA id ci4sm55175922pbb.50.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 12:20:40 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_EAAF6363-17B1-4204-8DB0-0CF29F74142A"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: (DMARC) We've been here before, was Why mailing lists
From: Douglas Otis <>
In-Reply-To: <>
Date: Thu, 17 Apr 2014 12:20:40 -0700
Message-Id: <>
References: <>
X-Mailer: Apple Mail (2.1874)
Cc: Pete Resnick <>, John R Levine <>, "" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Apr 2014 19:20:53 -0000

On Apr 17, 2014, at 11:18 AM, Martin Rex <> wrote:
> MUAs which are not implementing the rfc822/2822/5322 "on behalf of"
> semantics of a message that carries both From: and Sender: header
> fields ought to be FIXED.  Standards that build on rfc822/2822/5322
> and do not respect "on behalf of" semantics of messages with
> both "Sender:" and "From:" also need to be FIXED.

Dear Martin,

Merging Sender and From header fields by MUAs offers no protection when actual sources of messages remain unknown.  ESPs would rather see various authorization schemes than actually offering a means to authenticate their domain responsible for introducing the message.  When there is phishing or spoofing detected, those introducing messages into the public mail stream must respond by removing access, but they would rather push the problem onto their recipients.

John Klensin has already indicated TLS has a problem at authenticating sending MTAs, the clients.  We now have The next step should be to permit DANE verification of the sending MTA and allow SMTP to become fully federated.

In the meantime, there is a way for From header field domains to publish a list of third-party services employed by their users.  This can be done in the form of hash labels that can even be secured using DNSSEC.  This information could then be used to permit meaningful policy exceptions where each provider is expected to act responsibly.

The actions of a few ESPs should not result in such meaningless reaction.

Douglas Otis