Hello, p=reject; pct=0 is equivalent to p=quarantine; pct=0.
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
