Re: [dmarc-ietf] Abolishing DMARC policy quarantine
Steve Atkins <steve@blighty.com> Sat, 15 June 2019 22:13 UTC
Return-Path: <steve@blighty.com>
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 633A412012A for <dmarc@ietfa.amsl.com>; Sat, 15 Jun 2019 15:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com
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 M0o4M4rOxN5g for <dmarc@ietfa.amsl.com>; Sat, 15 Jun 2019 15:13:18 -0700 (PDT)
Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id CEE311200C5 for <dmarc@ietf.org>; Sat, 15 Jun 2019 15:13:17 -0700 (PDT)
Received: from [192.168.0.88] (unknown [37.228.251.105]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 1AFD19F146 for <dmarc@ietf.org>; Sat, 15 Jun 2019 15:13:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1560636796; bh=BnzR9+fhthKL7bpIReS48G92oRIqnOuc4/DdLlGg3Hg=; h=From:Subject:Date:References:To:In-Reply-To:From; b=K/627I+nIHv0Y1vz+qOs9FBc/AYBE7pi7CkaIYaFrnWmSfBKadKteBzDJisHpaiTe PUU2e7hmyl9VzWCoWjmsTkwMRFCiV4fEMzNbQs8oEGi+BjroRzen06PC1CoMvvRrVB V3JnHM0mXZdh2Y6JFK63f61PR3Foq/rR4lCCpzas=
From: Steve Atkins <steve@blighty.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sat, 15 Jun 2019 23:13:13 +0100
References: <a8ac130a671f5bcd1bf9f09781325e84a9f1fda6.camel@aegee.org> <b35700fed33aea68cde9a10c492b90f25519ce30.camel@wemonitoremail.com> <d2c48fa6e0caec1c75f1cc21303bfe83a188cc33.camel@aegee.org> <5D0526BF.6090704@isdg.net> <b8ecdd470d5af9f8e2e3a2cfdf003cb1424cec15.camel@aegee.org>
To: dmarc <dmarc@ietf.org>
In-Reply-To: <b8ecdd470d5af9f8e2e3a2cfdf003cb1424cec15.camel@aegee.org>
Message-Id: <DDD4C10C-6CF0-4D1D-97DC-C050285FAF31@blighty.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/R9DSszrBIWa5SfA520wM8qDbovY>
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 22:13:21 -0000
> On Jun 15, 2019, at 9:25 PM, Дилян Палаузов <dilyan.palauzov@aegee.org> wrote: > > Hello, > > p=reject; pct=0 is equivalent to p=quarantine; pct=0. I've not been following this thread too closely so I might be missing something, but under current DMARC spec I don't think that's so - see section 6.6.4. If I've missed the point ... never mind, carry on. Cheers, Steve > > The rest of this email is about (against) handling p=reject and p=quarantine differently. Namely, where a server > rejects on p=reject and “quarantines” on p=quarantine. > > There are more examples, all under the category p=quarantine, where the spam filter does not think a message is spam and > DMARC fails (e.g. missing DKIM-Signature): > > — an autoresponder. The incoming email will be delivered as non-spam, as the spam filter does not classify the email as > spam. Would you suppress the autorespond (out-of-office/vacation) message, or will you take the risk to send bad > backscatters, risking lowering your IP reputation. Is it up to the domain owner of the original message decide on you > sending backscatters, by publishing slightly different dmarc policies? If you handle quarantine as reject there is no > such risk of getting bad IP reputation (under these concrete conditions). If no auto-responder is sent and the mail is > not classified as spam, the user will rely on the fact, that an autoresponder was sent… big fuzz. > > — an 1:1 alias to a different server. If your server thinks the email is not spam, but the server to which the alias is > redirected thinks the message is spam, or if the user marks it as spam, your IP reputation gets worse. If you handle > quarantine as reject there is no such risk. > > — a MLM (1:many alias), where anybody can send messages - same problem as above, just bigger damage. > > p=reject and p=quarantine both communicate, that all messages from a domain must have aligned, valid dkim signature or > aligned, valid spf result and that for messages from the domain failing DMARC, there must be some penalty. > > How many distinct penalty levels does a sending domain owner need? > > One, or more than one? Are two penalty levels enough? Is there justification for two penalty levels? Can the same > justification be used to introduce a third penalty level? What does the domain owner/sending domain want do > communicate, by using the first, second, or third penalty level? > > Currently the decisions on handling quarantine/reject in different ways are taken by: > * domain owners, who own a domain > * spammers, who use the domain of the domain owner, and let's say are distinct from the domain owners > * mailbox operators > > Not taken into account are the users. Why shall a user want to have more messages in its spam folder (assuming that the > quarantined message was at the end classified as spam and the email operator handles Reject and Quarantine differently) > versus handling p=quarantine as p=reject and having less Spam to pay attention for? > > About the costs, Quarantine meaning neither deliver, not reject, but something different, can be implemented in this > way: the operator does not deliver the emails failing DMARC for a domain with p=querantine to the users, but arranges > staff, to decide what to do. The costs for that staff, are the extra costs for having distinct handling of > Reject/Quarantine. If there is no such staff, and the decisions are taken by the users, then the costs are the same, > these just are shifted to the users. > > Finally, while DMARC can be used to communicate that all emails from a domain must PASS DMARC rules, why there is a need > to communicate what to do with emails that fail DMARC from: the domain? The DMARC specification can be simplified, by > leaving the hanlding of such emails ultimately up to the receiving host and then there is no need to iterate the options > at protocol level for the sending domain. (The option, that all emails from a domain must have aligned DKIM signatures, > but it is up to the recipient what to do with messages without valid dkim-signature or spf result is anyway missing)j > > Regards > Дилян > > On Sat, 2019-06-15 at 13:11 -0400, Hector Santos wrote: >> 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. >> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc
- [dmarc-ietf] Abolishing DMARC policy quarantine Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Ken O'Driscoll
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Laura Atkins
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Dotzero
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Vladimir Dubrovin
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Dotzero
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Vladimir Dubrovin
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Alessandro Vesely
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Steve Atkins
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Murray S. Kucherawy
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Vladimir Dubrovin
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Murray S. Kucherawy
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Steve Atkins
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Murray S. Kucherawy
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Dotzero
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Steve Atkins
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Alessandro Vesely
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Tim Wicinski
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Alessandro Vesely
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Murray S. Kucherawy
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Hector Santos
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Дилян Палаузов
- Re: [dmarc-ietf] Abolishing DMARC policy quaranti… Brandon Long