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


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to