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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
