> On Jun 15, 2019, at 9:25 PM, Дилян Палаузов <dilyan.palau...@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 mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
