On Sat, Aug 10, 2019 at 1:44 AM Дилян Палаузов <dilyan.palau...@aegee.org> wrote: > > Hello, > > to the idea to amend the existing definition of p=: > > quarantine: The Domain Owner wishes to have email that fails the > DMARC mechanism check be treated by Mail Receivers as > suspicious. Depending on the capabilities of the Mail > Receiver, this can mean "place into spam folder", "scrutinize > with additional intensity", and/or "flag as suspicious". > > the text “ > > The Domain Owner wishes in addition, that the sender of messages failing > DMARC are notified about the suspicious > handling with an appropriate rejection message. Senders not willing to be > notified that their message is suspicious, > shall use the NOTIFY=NEVER service extension. > > In the past, Domain Owner could express as wish either to reject or to > quarantine. Considering that from the options: > only reject; only qurantine; and quarantine, while notifying the sender about > the suspicious handling of the message; > nobody will choose only to quarantine, the interpretation of what the Domain > Owner wishes by publishing quarantine was > changed to include the rejection component.” > > so far two voices were against. The reasoning against the amendment is that > writing what the domain owner wants is just > its preference, not anything binding, and the current definition is > sufficient. > > My motivation in favour the amendment is, that currently nobody has the > practice to quarantine messages and inform the > sender of the special delivery status at the same time. Spelling more > precisely what the domain owner wants will > suggest the implementations to implement precisely that preference.
It's not standard, but Google does add a string DMARC:QUARANTINE to our 250 response to DATA for messages that policy evaluated to quarantine. I'm not sure anyone ever noticed, of course. We've been doing it since 2012. I'm not agreeing with the amendment, merely pointing this out. Sender notifications would have to be one of: 1) Something like Google does, some 2xx response that contains extra information the sending server would have to act on (which becomes challenging in forwarding situations) 2) A 5xx response but also accept the message so a DSN is generated by the sending (maybe intermediary) server. While I'm sure plenty of servers already do something like this at least for honeypots, this seems like a twisting of the standards. 3) A 2xx response, accept the message, and the receiver generating a DSN. This has the obvious typical backscatter issue. So, I can see why our implementor chose #1, but also the low utility of it. Brandon > > With other words, the sole reason why a receiving host does not notify the > sender for quarintined message might be, that > the receiving site has not come to this idea. The additional text removes > the cause. > > If there was a common practice by now to deliver as junk and reject with > appropriate text at SMTP level, then the > amendment would have been less necessary. > > Regards > Дилян > > > > > > > On Wed, 2019-08-07 at 08:13 -0700, Murray S. Kucherawy wrote: > > On Sat, Aug 3, 2019 at 12:02 AM Scott Kitterman <skl...@kitterman.com> > > wrote: > > > Policy is an indication of sender preference, not a directive the > > > receiver must follow. I think the definition is fine. If the sender > > > prefers failing messages be quarantined, then they should use that > > > policy. They won't get what they want in all cases and that's fine. > > > > This matches my understanding. > > > > -MSK > > _______________________________________________ > > 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 _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
