Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos <[e-mail]>]

Doug,  this is Wildcat! SMTP - one of the oldest SMPT packages around. Summary here:

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

Background:

Since 2003, out of the box, Wildcat! SMTP with add-on tools, wcSAP and wcDKIM, the mail flow is:

(Note: for the record, email is a small part of winserver.com, but a supportive part for many customer operations)

At SMTP, starting with remote client connection:

1) If Enabled, Check for DNS-RBL IP check, respond at step 8 in order to collect envelope data.
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 (Wildcat! Sender Authorization Protocol):

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 our integrated Wildcat! Internet Net Server mail 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 operators and 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 <[e-mail] <mailto:[e-mail]>> 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
>