Re: [dmarc-ietf] Abolishing DMARC policy quarantine

Hector Santos <> Wed, 12 June 2019 13:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27C581200E9 for <>; Wed, 12 Jun 2019 06:28:37 -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=fUqQVHHj; dkim=pass (1024-bit key) header.b=e2P58cJw
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BjSkz7BirHSV for <>; Wed, 12 Jun 2019 06:28:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F2F661200B3 for <>; Wed, 12 Jun 2019 06:28:34 -0700 (PDT)
DKIM-Signature: v=1;; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2172; t=1560346106;; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Mx+YeA+g19oD15w7pFPrq34nn5k=; b=fUqQVHHjs1Wn7JqjnqKFgdNXK5VnEHanSSzAsJU7jeQ3X0yT2QfUx4e1wyBxO9 hF0UT1jYJEdHCLOuho10NMLrZQJrCk+VDXPSQomD6GOct9ikE9LM1K5o7rXW5bCA QLcygDjau25HsjDInn0it1kw01ydW4Uo7BSmPqw5pRIpQ=
Received: by (Wildcat! SMTP Router v8.0.454.8) for; Wed, 12 Jun 2019 09:28:26 -0400
Authentication-Results:; dkim=pass header.s=tms1;
Received: from ([]) by (Wildcat! SMTP v8.0.454.8) with ESMTP id 1138545530.1.824; Wed, 12 Jun 2019 09:28:26 -0400
DKIM-Signature: v=1;; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2172; t=1560345906; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=KTKXx7s CreXllXO4ptbBsrIXyeYeDxrY+eBwZ1C8GgA=; b=e2P58cJwMZ9Xf9LJ8UlbJZy RMZsDwVGEoxCfRPgbmnOuyUsi/WB4ezMyYuBOFl78wiWjbcsAP8sBkLMBKYWGw7C Sr2AF0cAIwTQd/BRp5IpD02ef8j/keMQpEYjwOFRLg7EmGFuSXS3/Opjp8savcr1 KccoR9GLlieQ+XsJGR4k=
Received: by (Wildcat! SMTP Router v8.0.454.8) for; Wed, 12 Jun 2019 09:25:06 -0400
Received: from [] ([]) by (Wildcat! SMTP v8.0.454.8) with ESMTP id 2710761785.9.237068; Wed, 12 Jun 2019 09:25:05 -0400
Message-ID: <>
Date: Wed, 12 Jun 2019 09:28:26 -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
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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 13:28:37 -0000

On 6/11/2019 5:00 PM, Дилян Палаузов wrote:
> How about, deleting policy Quarantine and instead rephrasing policy Reject:
> It is up to the receiving server if it rejects messages failing DMARC, or accepts and delivers them as Junk.
> (This does not change the protocol, just the wording)

I think that is how it was thought it would be handled.  Don't take 
"rejection" literally, in fact, it can be a discard concept as well. 
  This is all about local policy. A receiver has the option, based on 
Local Policy and the implementation software to offer:

   (o) Reject with 55x before DATA state
   (_) Reject with 55x after DATA state (allows for collection of payload)
   (_) Accept with 250 and Discard
   (_) Accept with 250 and Quarantine

Whether systems actually do rejections are not, this has been 
discussed and debated over the years.  But in my view, the thinking 
has evolved to a realization that dynamic rejections at SMTP are real 
which complicates DMARC with the presumption the DATA is always 
received.  My take is that early systems always accepted mail because 
of scale/bulk needs and/or their software didn't yet have dynamic 
hooking, shimming, spawning, scripting capabilities at the SMTP state 
points.  With the advent of advanced hardware, Dynamic SMTP processing 
at the state points is a relatively new capability, 10-15 years 
perhaps, where spawning filters at the state point became feasible 
with a small sacrifice in SMTP session time increases.

We even had the discussions about SMTP idle wait time and even 
explored the idea of a "Keep Alive" concepts using a heart beat reply 
code. But it was discovered, back then (10 years?), that not all SMTP 
clients would not be capable to support a kept alive concept while a 
SMTP server is processing a transaction.  In theory, a SMTP hook has 
about 5 mins to complete otherwise a SMTP client can time out.  The 5 
mins for time outs is pretty out-dated so don't be surprise to see 
SMTP servers lowering it down to a few minutes or less due to SMTP 
clients not hanging up causing scaling problems.  But we do expect the 
SMTP client to wait 5 mins. :)