Menu
▾
▴
#101 default trusted authentication services doesn't work anymore
Forwarding a bug from a Debian user:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761444
Since the upgrade from 1.2.0 to 1.3.0, I see this when opendmarc
starts:
trusted authentication services: (none)
With the 1.2.0 version it properly reported the hostname as the
comment in the config file indicates. This seems to have resulted
in nothing being "pass" anymore but instead got "none" instead
until I set it manually in the config file.
The "(none)" means no trusted names are configured. The test for what A-Rs are trusted, however, does include a check for the MTA's name. The MTA name can't be reported at startup because it's provided by the MTA when it connects, not when the service starts.
Can you create a reproduction configuration and sample message that fail in test mode?
I'm not sure what the question is. In any case I never set up AuthservID so it seems to be picking that up properly itself, but I had to fill in the TrustedAuthservIDs.
Like the other bug report, this is with postfix and opendmarc running as milter.
Prior to 1.3.0, TrustedAuthservIDs included the value of AuthservID, which defaulted to the hostname. As of 1.3.0, TrustedAuthservIDs defaults to the empty set, and the MTA name (which isn't necessarily the same as the hostname) is included in it during evaluations. That's why you see "(none)" logged. Thus, this is intended behavior.
However, since the MTA name is always automatically trusted as of 1.3.0 (but not the hostname), you shouldn't see legitimate messages failing unless the MTA name and the name appearing in Authentication-Results fields aren't the same.
The hostname is what you get when you run the "hostname" command at the shell prompt. The MTA name is whatever name the MTA sends to the filter to identify itself. For example, your hostname might be "foo.example.com", but the MTA name might just be "foo". This depends on how your MTA is set up to identify itself. opendmarc will thus by default trust Authentication-Results fields saying "foo", but not "foo.example.com", unless you specifically tell it to trust that name.
postfix is set up with "myhostname" the same as the hostname, and it's also the same thing as set in AuthservID.
To resolve the confusion about the meaning of the "(none)", in 1.3.1, that log entry will be changed to say "additional trusted authentication services". I'll also have it log the implicit authentication service name that's used for each transaction. That should enable us to figure out what's up either with your configuration or the code logic. This will be available in Beta1.
So I've added that commit, disabled the TrustedAuthservIDs and it indicates an "implicit authtentication service" with the correct hostname in the log. And I see all of none, pass and fail in the log file. So I have no idea why I reported this earlier.
OK, I'll close this out. Glad it's working! The modified logging will appear in 1.3.1 when it ships.
Scott, will you close out the Debian bug when 1.3.1 is out?
v1.3.1 released.