Since 2003, here is my out of the box, Wildcat! SMTP with wcSAP and wcDKIM
add-on support, mail flow:
(Note: for the record, email is a small Part, but a supportive part for many
customer operations)
At SMTP, starting with connection
1) If Enabled, Check for DNS-RBL IP check, respond at step 8
2.0) Check for smtpfilter-connect.wcx script, run it if found
2.1) Check for Geo-Location IP Blocks, very unethical practice.
3) HELO/EHLO: Check EHLO/HELO on technical merit like IP Literal matching
Connect IP (CIP)
4) MAIL FROM: Check for Local domain MAIL FROM spoof
5) MAIL FROM: Accept 250 pending RCPT validation
6) RCPT TO: not valid 550
7) RCPT TO: Valid starts WCSAP.WCX (p-code) Wait for Response.
At WCSAP:
8) WCSAP: Record if DNS-RBL IP blocked at 1, exit response 55z
9) WCSAP: Run sysop-defined text-based simple White/Block Accept/Reject If rules
10) WCSAP: Run SPF. Failure return 55z or 45z
11) WCSAP: Run CBV, Failure return 55z or 45z
12) WCSAP: return 250
Back to WCSMTP RCPT state
8) RCPT response provided, reject 55z/45z or 250 continue, Receiver-SPF header
prepended.
9) DATA is transferred, Received: trace line prepended.
10 Before DATA response, run stack of SMTP mail filters written in-house or 3rd
party:
At SMTPFILTER-xxxxxxx.wcx, specifically SMTPFILTER-DKIM-VERIFY.WCX
11) Check for ADSP + ATPS
12) Check For DMARC + ATPS
13) Record Authentication-Results
14) DMARC Rejection Failures are DISABLED. Auth-Res Prepended.
15) Return any 55z, 45z or 250 based on SMTPFILTER-xxxx,wcx filters.
Back to DATA,
16) DATA response is provided.
17) 250 mail is accepted, router signaled for MDA import or MTA forwarding.
18) Wait 30 seconds for client new transaction command, QUIT and/or DROP
Pretty much it.
We have too much invested in the integrated Wildcat! Internet Net Server
platform — one of the oldest platforms since the 80s.
My long time customers, sysops, sysadms, love the flexibility and p-code and
low code programmability for 3rd party developers!
I have provided the DMARC option to the SMTPFILTER-DKIM-VERIFY.WCX to return
55z response for DMARC p=reject but it is compiler disabled. However, anyone
can write a new mail filter script to run at DATA for DMARC, but it has yet to
happen. Not surprise there. If we don’t provide it, I don’t expect them to
do it.
In WCSAP, the SPF handling of the result can be set to not reply with 55z for a
SPF hard failure.
This will allow SMTPFILTER-DKIM-VERIFY.WCX to see a SPF=fail Received-SPF
header. But at the moment, out of the box, DMARC will never see a SPF reject.
From an innocent IETF implementor, my integration enhancement for DMARC might
be:
With SUBMITTER enabled, you will MOST DEFINITELY see this from supportive
clients:
C: MAIL FROM:<return-path> SUBMITTER=pra
where pra is Purported Responsible Address, normally 5322.From, Low volume or
not, you will see it.
I plan to use the PRA to get DMARC information.
First I will assume the signer is aligned so the next check is for return-path
alignment.
Second, if auth=dkim tag exist, I could offer an option to relax SPF in both
WCSAP.WCX and SMTPFILTER-DKIM-VERIFY.WCX.
Without some signal at wcSMTP about DMARC, SPF will most likely remain a hard
rejection at WCSAP/SMTP (at RCPT state) before DMARC at DATA.
—
HLS
> On Jun 27, 2023, at 7:58 AM, Douglas Foster
> <dougfoster.emailstanda...@gmail.com> wrote:
>
> Ale, here is an attempt at a formal model. Application to the current
> question is at the very end.
>
> Any test (DKIM, SPF, ARC) has these result possibilities:
> Pass
> No data or uncertain result
> Fail
>
> The test results are imperfect, so we have to consider these probabilities
>
> Probability that PASS is a correct result
> Probability that a false PASS will be whitelisted or not blocked in
> content filtering
> Net result that a false PASS is delivered to the user
>
> Probability that a NoData / Uncertain result is correct (presumed 100%).
> Probability that an Uncertain message is wanted or unwanted.
> Probability that an unwanted message is or is not blocked by
> content filtering
> Net probability that an unauthenticated and unwanted message
> is delivered to the user
>
> Probability that FAIL is a correct result
> Probability that a FAIL result is blocked by local policy (presumed
> 100%)
> Probability that a false FAIL is actually wanted
> Net probability that false FAIL blocks a wanted message
>
> My strategy is documented in my "Best Practices" draft submission. To
> summarize my experience:
> - The frequency of a true PASS is high, so the probability of a false PASS is
> low
> - The probability of a false PASS being detected by content filtering is
> pretty good.
> - The frequency of a true FAIL is low, so the probability of a false FAIL is
> high.
> - Uncertain messages have a high percentage of unwanted messages, but also a
> non-trivial volume of wanted messages.
>
> My conclusions:
> FAIL messages should be submitted to content filtering to collect more data
> Blocking on FAIL alone, despite content filtering PASS, has always caused me
> more harm than good.
> Treating UNCERTAIN as equivalent to PASS is harmful. Uncertain messages can
> be as unwanted as FAIL.
> FAIL and UNCERTAIN messages need to be reviewed and confirmed. When
> confirmed, the message is allowed or blocked based on local policies which
> are informed but not controlled by the sender's published policies.
> Quarantine on FAIL or UNCERTAIN is superior to Block, because it allows for
> ambiguity to be removed and policy rules to be updated
> When FAIL and UNCERTAIN volumes are too high, an arbitrary disposition can be
> applied immediately, but statistical sampling should be used to review the
> disposition decision after the fact, so that local policies can be updated.
> Application to the current AUTH proposal:
> I expect SPF AND DKIM will cause sender policies to be less believable,
> because a high rate of FAIL will occur on wanted messages, so I expect to
> treat SPF AND DKIM as SPF OR DKIM by local policy.
> I trust DKIM more than SPF so I see no reason to honor SPF ONLY. I will
> continue to apply SPF OR DKIM .
> I see the advantages of DKIM ONLY and will honor that policy when it is
> detected.
> Doug Foster
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
