Re: [dmarc-ietf] Abolishing DMARC policy quarantine

Hector Santos <> Wed, 12 June 2019 14:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB24D1200B3 for <>; Wed, 12 Jun 2019 07:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=bpny7dj/; dkim=pass (1024-bit key) header.b=JX5DPS87
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kWWVYfAz_z8l for <>; Wed, 12 Jun 2019 07:06:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 18D3D1200A4 for <>; Wed, 12 Jun 2019 07:06:25 -0700 (PDT)
DKIM-Signature: v=1;; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1532; t=1560348381;; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Y4Q/tr3ZyyJIY4CtnujQ+/xgkAY=; b=bpny7dj/Jwcu7IywDVZzhOEmjdeNUtA28RLm/0BFn/fEMuCE4THv03r8Sebyrl 6hsc00R/FxaJVkW+fll6ahgYKhIvVnLVBttr2A8P6t0pUEr+LG8a2oO23VtQRbaa ErU9qtoYGNaDQUkHQ01T8J3lIkKLbCBzw77nosDd7bzmM=
Received: by (Wildcat! SMTP Router v8.0.454.8) for; Wed, 12 Jun 2019 10:06:21 -0400
Authentication-Results:; dkim=pass header.s=tms1;
Received: from ([]) by (Wildcat! SMTP v8.0.454.8) with ESMTP id 1140820586.1.2484; Wed, 12 Jun 2019 10:06:21 -0400
DKIM-Signature: v=1;; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1532; t=1560348182; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=7i4goDA /s6q4Mr4buGO0iFlr4kOsTodIAB44+mA0j6k=; b=JX5DPS87/zUXmp7RpMU0Ff9 DKif2TIKvQOEQy0TXzMC8NxYCWEHGK+I3Sqdcssw1C53vguI2yOzPqUKVy4C9WUI i/zYfmO55OqqhQGrkE4Ww+Wt/AhMXwCx6fCGQWBKHf40IqEjo+9ra6W5FWVjIVh+ xyVqoBi4IQGdpcW6j/EY=
Received: by (Wildcat! SMTP Router v8.0.454.8) for; Wed, 12 Jun 2019 10:03:02 -0400
Received: from [] ([]) by (Wildcat! SMTP v8.0.454.8) with ESMTP id 2713037598.9.55012; Wed, 12 Jun 2019 10:03:01 -0400
Message-ID: <>
Date: Wed, 12 Jun 2019 10:06:22 -0400
From: Hector Santos <>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: Laura Atkins <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Jun 2019 14:06:28 -0000

On 6/12/2019 9:37 AM, Laura Atkins wrote:
>> On 12 Jun 2019, at 14:28, Hector Santos
>>  (o) Reject with 55x before DATA state
> Given that the 5322.from is crucial for DMARC, and the 5322.from is
> transmitted after DATA, how can you evaluate DMARC before DATA?

When SPF is taking into account.  But yes, overall, my comment was 
more about the whole "rejection" issue whether it was with SPF or with 
the DATA payload technologies since MARID; SenderID, Domainkeys, DKIM, 
  then ADSP, now DMARC.  The "To Reject or Not Reject" question was 
always there.

With SPF and DMARC, for example, if the receiver was made aware of the 
5322.From before the DATA state, this would preempt the need to 
receive the payload in order to get reporting information or perhaps 
get DMARC overriding deposition, i.e. p=quarantine overrides SPF -ALL 


Well today, we had the PRA/SUBMITTER protocol used to pass the 
Purported Responsible Address via MAIL FROM:

    C: MAIL FROM:<return-path> SUBMITTER=pra

Many clients do use SUBMITTER. Enable it and they will pop up.  Since 
we deprecated submitter when SPF was made standard track, imto, it may 
be a good idea to explore leveraging this protocol to support DMARC at 

I know this is just an optimization. But I would prefer this 
optimization over the idea of accepting a potentially large payload of 
a SPF -ALL failure just to find out if there is a DMARC record because 
the operator may want to see such SPF only failures.