Test qmail-inject recipient address qualification.

[schmonz]

Using qmail-qfilter (proposed in #227), turn the minimal reproducer from #147 into an automated regression test. It's an integration test, not a unit test, because it executes qmail-inject[*] the same way our systems would. Thanks to qmail-qfilter, the test does not involve a real queue in any way.

#229 probably fixes #147, and these tests will help us be confident of that.

[*] Or rather, tests/testable/qmail-inject, which is identical modulo linking with a custom definition of auto_qmail that points into the source tree

[DerDakon]

Almost there ;)

I would very much prefer to not have to create a separate inject binary. Would it be possible to let the filter grep for the expected "To: " line and return success or failure? Then it should be possible to just qmail-inject and look at it's return code to see if the filter has accepted the mail or not. At least that would be the solution with the least possible side effects I can think of.

[schmonz]

Yes, I'd feel much better if we could directly test the real qmail-inject we're about to install. Trouble is, before we've installed, qmail-inject hits die_chdir() -- and if we have installed notqmail already, /var/qmail is still the wrong place to be looking. So at least in this one case so far, we need a way to override the value of auto_qmail for testing.

But how? Linker tricks aren't portable enough. Relinking a fake auto_qmail into the real qmail-inject is a no-no (people need to be able to run the tests and then install). Maybe we introduce an environment variable for the purpose of overriding auto_qmail, being careful to name it something strange enough that no admin would happen to already have it set? Other options?

[DerDakon]

I wonder why all tests pass if this should detect the regression?

[schmonz]

I've made the failing test fail the build, so the checks should look uniformly bad now :-)

In an attempt to avoid

• hand-duplicating an entire rule just so I can hand-change a tiny part of it
• relying on non-portable linker tricks
• introducing a test-motivated environment variable (and function lookup) into production code
• using chroot or another workaround that would require running tests as root

... tests can depend on testable. integrationtest_inject depends on it, causing the top-level build to be copied into a subdirectory of tests where it can be messed with in unsurprising ways.

Copying seems wasteful, but for our autobuilds the time consumed is in the noise, and for local development we don't need to be running the integrationtest target most of the time, just the unittest target.

This approach seems weird but also obvious enough that we'll be unlikely to screw things up.

[schmonz]

Also, the filter no longer drops a sentinel-file turd to indicate the bug. Instead it uses the customerror API from #195. Perfect fit :-)

[josuah]

This branch does not touch to any existing file beyond the Makefile.
This means very easy to integrate into an existing QMAIL setup.
It also should be straightforward to resolve the merge conflicts thanks to this.

[josuah]

Given setenv(3) is in POSIX,
https://pubs.opengroup.org/onlinepubs/9699919799/functions/setenv.html

I am simply curious about which system does not support it.
Maybe you ran into an counterexample?

[josuah]

The POSIX one also has no vallen, I see in the rest of the code why this was desired.
This also means using memcpy for '\0'-terminated strings, which could be error-prone, but it looks correctly handled in all invocations of mysetenv.

[josuah]

I like it! Disk storage, no cleanup needed.