First, I am working with a few people directly to get try to quickly
get exim DMARC capable by using perl scripts since DMARC support in
perl is pretty thorough. I'm viewing it as the quickest way to get a
feature until said support can be built in.
For the longer term, I have begun this work. I put together the start
of DMARC support built in to exim, protected by feature name
EXPERIMENTAL_DMARC. It is not yet in a modular format like DKIM is
implemented in separate dkim.{h,c} files. For ease of testing
purposes, I'm doing it all inline in src/receive.c.
What I have so far is visible in my staging area at
http://git.exim.org/users/tlyons/exim.git/shortlog/refs/heads/master_opendmarc.
A comprehensive diff can be obtained with:
git diff c41c0f1a1c^..HEAD
Recap: It's not modular, there are no global knobs yet, there are no
ACL control functions, and there is no ACL or router/transport
feedback variables. The only way you even know it's doing anything is
because it logs a single line to the mainlog:
LOG: 1THinf-0002Zc-KY DMARC results: spf_domain=mrball.net
dmarc_domain=misterball.com spf_align=no dkim_align=no
Under gdb and simulated connection (-bh IP) it's doing everything
expected, so next week I'm going to apply this to one of my production
servers to see if:
1. It works. (my string handling is liable to be subpar and segfault worthy)
2. It's stable. (again, strings)
3. It's correct. (strings and free'ing)
It adds an external dependency, libopendmarc, but that's not a problem IMHO.
With positive results, I'll see about modularizing it and adding knobs
and controls and feedback variables.
...Todd
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine
