Re: [dmarc-ietf] New proposed wording for p=quarantiine

[Dotzero <[e-mail]>]

On Sat, Aug 10, 2019 at 4:44 AM Дилян Палаузов <[e-mail]>
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.
>

I'll add a third voice. When we came up with DMARC - yes, I was part of the
original dmarc.org team -  we were extremely cognizant of the fact that
there is no way to bind receivers/validators to the preferences expressed
by senders. The whole purpose of DMARC was to take something that was
working through private contractual agreements in a private group and make
it available more generally and publicly. Today there are receivers which
only make reporting available on a contractual basis through 3rd party
intermediaries or because there are direct relationships between the sender
and receiver. It is important to recognize what is required for
interoperability (in a standard) and what is a want that goes beyond what
is appropriate for a standard documenting technical interoperability.

>
> 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.
>
> 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.
>

Technical standards, as a general rule, should not be written based on
suppositions with regard to hypothetical causations that lack any empirical
evidence to support those suppositions. One could just as easily suppose
that the reason that receiving hosts do not notify the purported sending
domain is that they believe it is a bad idea. In either case it is a
supposition without any validation. We are not mind readers.


>
> 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.
>
>
You are asserting the amendment is necessary but you are providing no data
to support your assertion. My experience covering a corpus of billions of
emails does not support your assertion.   I therefore agree with Scott and
Murray that no amendment is appropriate in this case.

Michael Hammer