Συντάκτης: Todd Lyons Ημερομηνία: Προς: Todd Lyons, Jeremy Harris, exim-dev Αντικείμενο: Re: [exim-dev] Exim support for OpenDMARC
On Mon, Apr 1, 2013 at 4:10 PM, Phil Pennock <pdp@???> wrote:
> > Honestly the test suite has been somewhat of an enigma for me. The
> > SPF and DKIM libraries require live lookups, whereas I could stuff dns
> > values into the DMARC library. Phil advised that live lookups were
> > better so long as we controlled the data it looked up, so that's what
> > I tried to use (first tried against my own dns server). But when it
> > came right down to it, the exact same commands run under the test
> > suite performed differently WRT dkim/dmarc from when I ran the same
> > command manually. I never did zero in on the problem, so I pushed it
> > back to "look at it later" status. If no test suite is a show stopper
> > for an experimental feature, I'll have to delve more deeply into the
> > behavior I was seeing.
>
> Test-suite overrides a lot of DNS initialisation; this makes it awkward
> to test real-world interactions.
Jives with what I was seeing, but all along I felt I was missing the
bigger picture. More detailed analysis will be required before I can
state that I fully understand things that are happening during test
suite operation.
> Normally, I'd say that "no test suite is an argument for keeping
> something in experimental rather than main" and we wouldn't press hard
> for a contribution to have accompanying tests, but if code is going to
> be extensively changing existing files, it becomes more important to be
> able test the impact of the changes.
My goal with tests for the test suite were that I would be able to
establish a baseline for dmarc code operation, and be able to detect
future changes in operation and behavior. If the focus is "make sure
that we don't affect any existing code operation, that should be the
case now because:
1. If EXPERIMENTAL_DMARC is not defined, all of the code is ifdef'd out.
2. If EXPERIMENTAL_DMARC is defined at build time, but no global
configuration options exist in the config file, the functions are
designed to be entered, detect no configuration, then exit
immediately, specifically with no type of output.
3. If EXPERIMENTAL_DMARC is defined at build time, and global
configuration items exist, but nothing is called in the acl's, the
functions are designed to be entered, prepare variables (no output),
but the processing is never called by the acl's, so the core
processing function is never called (which would be the beginning of
debug and logfile output).
So I think that as it stands, I need to verify that the test suite
output is consistent between master and my code for each of the 3
modes designated above. If it's not, I need to adjust my code to make
it so.
...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