I think this construct is explained/mentioned in several places in the
documentation. Section 20 of chapter 44 is one of them: "An exclamation
mark preceding a condition negates its result."
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-access_control_lists.html#SECTcondmodproc
You should read it as !(...)
(despite the counter-intuitive spacing)
And please allow me to bring to your attention this message I sent a
couple of days ago:
https://lists.exim.org/lurker/message/20200711.202132.cfd68318.en.html
It contains the configurations for SPF/DKIM/DMARC that I created for
Exim on CentOS 8.
On 7/16/20 2:25 AM, Phillip Carroll via Exim-users wrote:
> To the maintainers:
>
> Help needed with a small grammar explanation.
>
> At the moment I am interested in (at long last) making my exim.conf
> somewhat aware of SPF/DKIM/DMARC in some regard, which has led me to
> perusal of Chapter 58 of the exim 4.94 spec.
>
> Coming from a world of Context-Free Grammars in general, and Backus_Naur
> in particular, I frequently find myself bewildered by exim's---shall we
> say---"interesting" configuration grammar. Nevertheless, I usually
> manage after an exhaustive search of the latest version of the exim spec
> to make sense of any constructs I come across in examples.
>
> However, the DMARC example of 58.5 contains a construct that has me
> totally stumped:
>
> warn !domains = +screwed_up_dmarc_records
>
> In an exhaustive search of the PDF version of the spec, I found exactly
> 98 occurrences of the symbol "!". Exactly one of those 98 instances (the
> line quoted above) contains "!domains". None of the other 97 instances
> appear to satisfactorily explain how to interpret the construct in
> question.
>
> Presumably the left side of the "=" is negated in some manner, but that
> is about as much as I think I understand. The right side looks
> sufficiently close (linguistically speaking) to "foobar" that I think I
> have some glimmer of understanding of that. But, maybe not.
>
> A pointer to the specific section of the spec that explains the concept
> I am missing would be sufficient.
>
> Phil
