Re: [dmarc-ietf] p=quarantine

[Hector Santos <[e-mail]>]

On 12/10/2020 9:26 PM, Dave Crocker wrote:
> On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote:
>> I think that is much closer to the right semantic but highlights a
>> problem that the mail coming from a particular domain probably
>> doesn't rate a single broad-brush characterization of seriousness.
>
> I've assumed the none, quarantine, reject choices are meant to
> indicate just how certain the domain owner is that the mail is
> problematic.
>
> Perhaps:
>+
>      none: not certain at all
>
>      quarantine: I believe I've got control of all my sending, but am
> not 100% positive
>
>      reject: I have control of all my sending; if it doesn't pass
> DMARC, it's use of the domain is bogus.


When it comes to keeping focus with the purpose of SPF and DKIM-POLICY 
protocols and its implementation out of the box, default behavior:

1) The main purpose is Receiver Abuse Control.

2) Special attention to Port 25 Unsolicited Anonymous Senders and 
Message Authors.

3) For authenticated, authorized, white listed clients, SPF and DKIM 
do not apply, mail is always accepted.

Hard policies with SPF and DKIM-POLICY are honored aggressively. 
Softer policies are processed, classified and passed through to next 
filters, if any remaining, i.e. GreyListing.

* SPF -ALL, REJECT - Receiver rejects at MAIL FROM state with a 550 
response.

* ADSP DKIM=DISCARDABLE, Receiver rejects at SMTP DATA state with a 
negative 550 DATA response.

* DMARC p=reject, Receiver rejects at SMTP DATA state with a negative 
550 DATA response.

* DMARC p=quarantine, Receiver accepts at SMTP. Mail is moved outside 
targeted users' main inbox mail stream, i.e. can not be picked up by 
user's POP3 or normal mail pickup process. The user has to login in 
online to see the mail in another non-inbox folder, i.e. spam box.

Thats it.  No reporting. Period.

The domain should be grateful their public mail policy instructions is 
being honored for strict operations at compliant receivers. I hope 
their compliant receivers are also honoring our strict public mail 
policies as well to help protect fraudulent usage. I really do not 
need a report for the expected action when fraudulent mail is detected.

Overall, the receiver is doing the domain a favor by helping them 
protect their domain reputation from possible fraudulent usage of 
their domains, and at the same time, it is helping its own system and 
the target hosted user from potential abuse as well -- a win win 
situation.

For List-related situations, the receiver follows the 2006 DSAP 
recommendations:

https://tools.ietf.org/html/draft-santos-dkim-dsap-00

1) If a new subscribing domain has a restrictive public mail policy 
with ADSP and/or DMARC, the subscription is denied.

2) Incoming messages are checked for mailing list destinations. If the 
submitter's domain have restrictive public mail policies with ADSP or 
DMARC, the submission is rejected with a 550.

With these two simple peripheral filters, there was no need to modify 
the legacy list server source code for Rewriting or anything else 
related to the "in-direct" mail problem.

The DMARCbis codification/changes I am looking for are:

1) Improvements in the DNS lookup algorithm, optional additional 
lookups should be provided or referenced.

2) Recognition and support for ATPS to cover 3rd party authorization.

and other fine tunning, clarifications, for example, in another 
thread, it was stated:

"When you switch to p=quarantine pct=0, no one should apply quarantine 
(so it's equivalent to p=none),"

I thought the "pct=" was related to when reporting should be applied. 
I apparently read it wrong.  This needs to be code reviewed and 
corrected on our end, if needed.  We are not doing reporting at this 
time.  Not the main focus.  That can come later as an augmented 
feature, in fact, we might consider it as a paid service to be sending 
thousands report out to domains.

Keep it simple folks.  Be safe and have a great weekend.

Thanks

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos