Re: [dmarc-ietf] Abolishing DMARC policy quarantine

Hector Santos <hsantos@isdg.net> Sat, 15 June 2019 17:17 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE4E12002F for <dmarc@ietfa.amsl.com>; Sat, 15 Jun 2019 10:17:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=TqL7q5wW; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=0XivkPG9
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dH3zpl_7qYCW for <dmarc@ietfa.amsl.com>; Sat, 15 Jun 2019 10:17:01 -0700 (PDT)
Received: from mail.winserver.com (ntbbs.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id C34E9120092 for <dmarc@ietf.org>; Sat, 15 Jun 2019 10:17:00 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3437; t=1560619013; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=1exZ+q//HyF6v7pj6v/XMSnWOfk=; b=TqL7q5wWmATDoUyCpaYF+lE5vfwQd5A6BYA5d/+UBcFfR49bUX+W8OImaSmTq7 VwiIbBCYfax8cJQJ2Manwt5Be8Dy9PjO0EZuz+hwMfkL7YKa8Jc9/KxJrEtSDwtn Y3kQcuEuEIbQIZZv6RK/e1rdVdwFJ2NNIQ/MOR0svmytw=
Received: by winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Sat, 15 Jun 2019 13:16:53 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1411449545.25538.3092; Sat, 15 Jun 2019 13:16:53 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3437; t=1560618476; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=8QwTLvl H9A4JzHdmv4NLFMpDoHJyXUZXxRxEG47X0FI=; b=0XivkPG9Nz2v5MWeQfRjgtS shYJDnT4t2ZzKiIp1HtOieEQWMrvt5rGNgWRYz6IXTXqOwzLEki5v74HSweRQ8Zy xLOmnNY8vdGEW7t4Gtbo44UJNiJ95IW1JySr25wcq7gRkEiWLYTwmFd2ZW3ZDBUK qnHAhQ6BtZbyX6o02AXg=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Sat, 15 Jun 2019 13:07:56 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 2983331863.9.41408; Sat, 15 Jun 2019 13:07:56 -0400
Message-ID: <5D0526BF.6090704@isdg.net>
Date: Sat, 15 Jun 2019 13:11:27 -0400
From: Hector Santos <hsantos@isdg.net>
Reply-To: hsantos@isdg.net
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: dmarc@ietf.org
References: <a8ac130a671f5bcd1bf9f09781325e84a9f1fda6.camel@aegee.org> <b35700fed33aea68cde9a10c492b90f25519ce30.camel@wemonitoremail.com> <d2c48fa6e0caec1c75f1cc21303bfe83a188cc33.camel@aegee.org>
In-Reply-To: <d2c48fa6e0caec1c75f1cc21303bfe83a188cc33.camel@aegee.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/ZVQPAYQ-Y4M-WwjGQQ_U3OpPqrs>
Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Jun 2019 17:17:03 -0000

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