Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Hector Santos <[e-mail]>]

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. :)

-- 
HLS