Re: [dmarc-ietf] Abolishing DMARC policy quarantine

[Hector Santos <[e-mail]>]

On 6/14/2019 5:58 PM, Дилян Палаузов wrote:
> Hello Ken,
>
> effectively I proposed handling p=reject and p=quarantine the same way.
>
> ..
>
> Lets have an example for p=quaranite:
>  majordomo@domain is an address where commands are sent and the software receiving the
>  command always sends an answer, even if the command is unclear.  An email is sent
>  to majordomo@domain.  The sending domain has published policy Quarantine.  This address
>  has no spam/junk folder attached to it.  The options for an email are:
>   * reject the email during the SMTP dialog
>   * accept the email and let majordomo send an answer to it
>   * arrange a human to decide which emails to discard (handle an imaginary Spam folder for the account).

Oh I see your concern/point/proposal now.

Yes, I highlighted this basic issue in years past in regards to the 
handling semantics debates. Even with SPF,  how -ALL (FAIL) was 
interpreted and handled was questioned. Some believed a -ALL FAIL 
policy is more like a quarantine because "no one actually rejects."

But overall, this would be an implementation consideration, not a 
protocol design consideration. The protocol is correct to have a 
handling semantics describing both ideas - reject and quarantine.

All we can do is highlight the existence of backend mail storage 
designs and legacy MUA protocol(s) that can not handle a quarantine 
safely. So at best, you can basically highlight the security design 
concerns and possible requirements to implement a quarantine concept.

There is much mail design history and evolution to consider. The 
concept of quarantine came with the integrated mail design premise that:

- The backend offers user folders or separate mail streams for normal 
in-box mail and quarantine, spam, junk mail separations. While this is 
common today for ESPs, this was not always the case for all backend 
designs.  It was often proprietary in nature.  No standard here unless 
we assume everyone using an "Microsoft Exchange" (MAPI) concept or 
IMAP which is not reality. This coincides with the premise,

- The broad range of online and offline MUAs all support the 
multi-folders provided by the backend.  This is again not reality and 
not always the case.

I'll give you a perfect example -- POP3.

POP3 is a single mail stream pick up protocol standard. So for a 
backend that provides POP3 service available to its customers and for 
the user using MUA with POP3 support, the backend POP3 server MUST NOT 
merge any suspicious, spam, junk or quarantine mail with the user's 
normal in-box mail pick up stream.

While an advanced POP3 backend server can emulate a single stream 
consolidation of multi-user folders, it would a major security loop 
hole to expose POP3 users to quarantined mail merged into the user's 
pop3 mail stream.  For this to work securely, this advanced POP3 
server must assume the MUAs are advanced enough or users are advanced 
enough to write MUA scripts that will separate the single pop3 stream 
into spam, junk and quarantine folders again.

All we can do is highlight how "rejects" can be interpreted 
differently.  After much discussion with SPF, while it didn't provide 
an specific example using POP3, it was generically described under 
Local Policy Considerations:

    https://tools.ietf.org/html/rfc7208#appendix-G.2

It should also be highlighted for DMARC-bis, if not already.

-- 
HLS