Re: [dmarc-ietf] Improving feedback using additional status codes

[Dilyan Palauzov <[e-mail]>]

Hello Douglas,

RFC 7372 describes these status codes.  To my knowledge these are not used.

SPF helps on DMARC with MTAs, which cannot include DKIM signature  
under circumstances (e.g in bounces).  In all othercases SPF does not  
provide added value to DKIM.

If you want errors about failed DKIM validation, remove the SPF  
records, set DMARC policy reject and scan your logs for rejected  
messages to see on which messages DMARC/DKIM have failed.

Regards
   Дилян

----- Message from "Douglas E. Foster" <[e-mail]>  
---------
     Date: Sat, 25 May 2019 15:42:57 -0400
     From: "Douglas E. Foster" <[e-mail]>
Reply-To: [e-mail]
  Subject: [dmarc-ietf] Improving feedback using additional status codes
       To: [e-mail]


> The genius of DMARC, as compared to DKIM and SPF alone, is the feedback
> component.   Unfortunately, sender authentication remains challenged by
> these issues:
>   	Limited deployment of DMARC feedback between senders and receivers.
> 	  	Significant levels of SPF and DKIM validation errors, on legitimate
> mail, even when indirect mail is not involved.  Handling false positives
> becomes a significant obstacle to implementation of Sender Authentication
> by receivers.
> 	  	When the sender has not implemented DMARC, the recipient has difficulty
> communicating with the sender about Sender Authentication problems.
> Finding a knowledgeable employee is difficult and time consuming, so it
> will rarely be attempted.  (And I have tried it.)
>  I propose two improvements to deal with this issue.  The first is to
> define another feedback mechanism using message reception status code.
> The second is intended to reduce DKIM verification errors, and will be
> posted later.
>
>  PROPOSAL
>
>  When a recipient detects an SPF or DKIM problem, it can provide immediate
> feedback to the sender with message status codes.  I think these are a
> complete list of the conditions which would need a result status defined.
> The approach should be entirely upward-compatible with the existing
> infrastructure.
>
>   Message Success with SPF warning
>   	Accepted despite SPF=NONE & Source IP not in MX list 	Accepted despite
> SPF=NEUTRAL 	Accepted despite SPF=SOFTFAIL 	Accepted despite SPF=FAIL
> 	Accepted despite SPF TempError 	Accepted despite SPF PermError
>  Message PermFail because of SPF
>   	Rejected because of SPF=NONE & Source IP not in MX list 	Rejected
> because of SPF=NEUTRAL 	Rejected because of SPF=SOFTFAIL 	Rejected because
> of SPF=FAIL 	Rejected because of SPF TempError 	Rejected because of SPF
> PermError
>  Message TempFail because of SPF
>   	TempFail due to SPF TempError
>
>   Message accepted despite DKIM
>   	Accepted despite DKIM PermError 	Accepted despite DKIM TempError
>  Message PermFail because of DKIM (not recommended)
>   	Rejected because of DKIM PermError 	Rejected because of DKIM TempError
>  Message TempFail because of DKIM
>   	TempFail because of DKIM TempFail
>
>  Since DMARC evaluation is based on SPF and DKIM evaluated together, the
> above codes would seem applicable even with DMARC enforcement.   I think
> these additional codes should be sufficient:
>   	DMARC PermError (invalid policy record) 	DMARC TempError (problem
> retrieving policy record.)
>  Is this reasonable?
>
>  Doug Foster


----- End message from "Douglas E. Foster"  
<[e-mail]> -----