Re: [exim] Unsigned messages from DKIM domains

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Ivo Truxa
Dátum:  
Címzett: Exim-users
Tárgy: Re: [exim] Unsigned messages from DKIM domains
I am putting the following text at the top, but please read also my answers to your comments below too:

There is one very IMPORTANT thing that you do not seem to understand, and that is that DMARC does not replace DKIM, and that there are things you can do with DKIM, but cannot do with DMARC alone. Especially, DMARC has currently no way to declare the DKIM signing policies! The only thing that you can declare with DMARC policies, is what should be done with a message not aligning with DMARC. And there are currently only three options:
- 'none' (RFC7489: The Domain Owner requests no specific action be taken regarding delivery of messages);
- 'quarantine' (RFC7489: The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as Suspicious)
- 'reject' (RFC7489: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check.)

In other words, THERE IS (currently) NO WAY in DMARC's policies to declare that all messages from a domain have to be signed. If a domain DOES NOT HAVE DK (historical), DKIM, or ADSP policies about signing, DMARC will only fail with a failed/invalid signature, but will be quite fine with a missing signature!!!! And that's exactly the problem I am addressing here! You REALLY HAVE TO declare in your DKIM (or ADSP) policies that all your email HAS TO BE SIGNED! If you have no DKIM/ADSP policies, DMARC won't help you! Sorry about that, but you really should be aware of it, and reread the DMARC specifications (RFC7489 https://tools.ietf.org/html/rfc7489).

Please continue reading my comments below:

> -----Original Message-----
> Richard Clayton
> >Why wouldn't I? Do you use to send unsigned messages while claiming in the
> >signing policies published in the DNS that all messages from your domain are
> >supposed to be signed?
>
> I publish a DKIM key ... I make no policy claim as to what the presence
> of that key does or does not mean...


Then I see no problem, and no reason why my server should be rejecting you messages. It only rejects unsinged messages from domains that declare all their mail MUST be signed, in their DK, DKIM, or ADSP policies in the DNS.


> ... in fact my DMARC policy statement says that you should let me know
> what you observe about email messages that you receive from me (and what
> their signing status is), but I explicitly neither recommend that you
> treat these messages as spam nor that you reject them


> publishing a DKIM key without DMARC is NOT a policy statement !


That's correct. You have to publish the policy separately, but you do not need DMARC for it.

> >In that case your email indeed deserves to be rejected.
> you may treat my email as you wish -- your loss (in my view)


I treat all email equally. Unsigned email from domains claiming all email to be is rejected. If you have no policy about DKIM in your DNS, or permit also unsigned email, there is no problem.


> DMARC policies are for receivers to understand the policy of the sender;
> you should, in my view, always take note of it when it is present


That's exactly why I use DMARC, and it takes care of it correctly. It does not take care of email from domains not using DMARC, though, and I cannot do anything about it.

> no -- use of DKIM is not a policy statement ... that's precisely why
> DMARC exists


DMARC is not equal DKIM. People who use DKIM and declare their policies through DK, DKIM, or ADSP policies do not necessarily also use DMARC. I still want to process their email correctly though.

> that's again wrong -- you should be honouring (for example) Paypal's
> p=reject because it is the DMARC policy that they go to some effort to
> publish, not because you think that Paypal is in some sense special


p=reject is a DMARC declaration, and is handled adequately by DMARC in Exim. The DKIM handles only DKIM, not DMARC. There is no need to parse the DMARC directives twice.

Greetings,
Ivo Truxa