FAIL: testPolicy (testpolicy.PolicyTestCase.testPolicy)

[kitterma]

This is not a new issue, but the test still fails on my system with 1.0.6. I have gotten as far as it's failing because of a key error (the one at the end of Milter.policy.MTAPolicy.getPolicy). I assume that there's something specific to the ancient BDB version we have in Debian due to licensing issues with newer versions, but I'm not sure. This is using bsddb3. I've attached a gzipped copy of the access.db created when I run the test. Suggestions?
access.tar.gz

[sdgathman]

The bsddb keys are bytes. There are two configs that you might need to set in the config file:
access_file_nulls
access_file_colon
Nulls is for systems that include the null terminator in the key. Colon is for systems that use a colon (':') separator in the key (other systems use '!'). You can use db_dump on the access file to see what your system does to the access file. (Does postscript even have an access file similar to sendmail?)

[sdgathman]

The access.db file you provided is empty. The testpolicy.py is supposed to use makemap to create the access.db for testing. Is makemap missing and test case should detect that?

$ hexdump aa.db
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0002800

[sdgathman]

The test case should probably do some preliminary key lookups to determine the settings for access_file_nulls and access_file_colon.

[kitterma]

So it is. I had one earlier that was not and the test still failed, but let me see if I can figure out why it ended up empty.

[kitterma]

This one is not empty. It gets the same failure.
access.tar.gz

[kitterma]

Is there something that's needed in the Sendmail configuration for this to work? When I'm running the test, I have it installed, but haven't done anything to configure it. It has whatever the default configuration is in Debian.

$ python3 testpolicy.py 
F
======================================================================
FAIL: testPolicy (__main__.PolicyTestCase.testPolicy)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pymilter-1.0.6/testpolicy.py", line 31, in testPolicy
    self.assertEqual(pol,'OK')
AssertionError: None != 'OK'

----------------------------------------------------------------------
Ran 1 test in 0.074s

FAILED (failures=1)

[sdgathman]

So the test passes with your access.db, AFTER I set access_file_nulls = False. So your sendmail install does not append nulls to keys. There is no user visible config for this, so I think the best approach to try a test key with and without nulls. It doesn't seem elegant to have config for the test suite. Same with the access_file_colon option.

It the test suite can self configure these, maybe policy.py should do so when these options are not set.

[sdgathman]

The problem with self configuring is that you need at least one known test key in the database.

Idea: if key is not found, and the nulls/colon configs are None, then try all four combinations. If one of them works, then set the configs accordingly. (If only one is set, try both possibilities.) If the key is still not found, then leave the nulls/colon configs unchanged.

[sdgathman]

Another approach to self-configure is to run makemap in /tmp with a key containing a colon. Is that too outlandish for a library routine?

[kitterma]

Sounds reasonable. Thanks for looking into it.

[sdgathman]

Sounds reasonable. Thanks for looking into it.

In the meantime, set access_file_nulls = 0 in your pymilter.conf or set the flag in your config object passed to MTAPolicy contructor.

[sdgathman]

All the RedHat derived sendmail installs include the key

Connect:localhost                       RELAY

in the default access file. I can add this to the test case access file. Do your Debian derived systems also include this in the default? @kitterma

[kitterma]

It does not. It's there, but commented out.

[sdgathman]

Too bad. That would have been a useful known key. I'm concerned with making void lookups take 4 times as long until a key is found. Maybe the auto configure should use iteration to find some known keys ...