[opendmarc-users] OT: Re: Rejecting DMARC errors

[Lefteris Tsintjelis]

On 13/6/2019 16:51, Juri Haberland wrote:
> Second, in your example with missing DKIM signature, OpenDMARC logged a 
> permerror which means, the sending domain got something wrong with their 
> DMARC records - how is a DMARC implementation supposed to know, what the 
> sending domain really wanted? Don't blame the messanger - the fault is 
> at the sending side.

Nothing is set wrong in the sending or the receiving domain. The message 
is pretty clear about this. The fault is not of the sending or the 
receiving side. It is an RFC implementation issue.

Authentication-Results: mail.domain.com; dkim=permerror (bad 
message/signature format)

This was just a test I run and was totally surprised of the result. 
Enforcing domain signature checking is the missing link here so IMHO, 
the RFC is to blame.

> ADSP is dead, the ADSP RFC was moved to historic 
> (https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/), 
> as it was never widely adopted - you seem to be one of the few really 
> using it.
> 
> In RFC 7489 in section 6.7 "Policy Enforcement Considerations" it says:
> 
>     DMARC-compliant Mail Receivers typically disregard any mail-handling
>     directive discovered as part of an authentication mechanism (e.g.,
>     Author Domain Signing Practices (ADSP), SPF) where a DMARC record is
>     also discovered that specifies a policy other than "none".  Deviating
>     from this practice introduces inconsistency among DMARC operators in
>     terms of handling of the message.  However, such deviation is not
>     proscribed.
> 
> 
> Furthermore appendix A.5 has a list of problems that ADSP has:
> 
> A.5.  Issues with ADSP in Operation
> 
>     DMARC has been characterized as a "super-ADSP" of sorts.
> 
>     Contributors to DMARC have compiled a list of issues associated with
>     ADSP, gained from operational experience, that have influenced the
>     direction of DMARC:
> 
>     1.  ADSP has no support for subdomains, i.e., the ADSP record for
>         example.com does not explicitly or implicitly apply to
>         subdomain.example.com.  If wildcarding is not applied, then
>         spammers can trivially bypass ADSP by sending from a subdomain
>         with no ADSP record.
> 
>     2.  Nonexistent subdomains are explicitly out of scope in ADSP.
>         There is nothing in ADSP that states receivers should simply
>         reject mail from NXDOMAINs regardless of ADSP policy (which of
>         course allows spammers to trivially bypass ADSP by sending email
>         from nonexistent subdomains).
> 
>     3.  ADSP has no operational advice on when to look up the ADSP
>         record.
> 
>     4.  ADSP has no support for using SPF as an auxiliary mechanism to
>         DKIM.
> 
>     5.  ADSP has no support for a slow rollout, i.e., no way to configure
>         a percentage of email on which the receiver should apply the
>         policy.  This is important for large-volume senders.
> 
>     6.  ADSP has no explicit support for an intermediate phase where the
>         receiver quarantines (e.g., sends to the recipient's "spam"
>         folder) rather than rejects the email.
> 
>     7.  The binding between the "From" header domain and DKIM is too
>         tight for ADSP; they must match exactly.
> 
> 
> That said, I'm not involved in creating any of those standards and if 
> you would like to discuss this topic further, you might better do it on 
> the dmarc-discuss mailing list (dmarc-discuss at dmarc.org) or on the IETF 
> dmarc mailing list (dmarc at ietf.org).

I never said ADSP was perfect but it sure was a good and unreplaced 
control mechanism to enforce domain signature checking. It is perfectly 
understandable of course that you are not involved and/or responsible 
for it. In any case, thank you for all the info and your help.

Cheers

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4151 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.trusteddomain.org/pipermail/opendmarc-users/attachments/20190614/d9d9081a/attachment.bin>