Hi Murray,
>> a) as presented, opendkim exits with segmentation fault at launchtime when
>> /etc/opendkim.conf says
>>
>> #SetupPolicyScript /etc/opendkim/setup_dont_spoof_localusers.lua
>> ScreenPolicyScript /etc/opendkim/setup_dont_spoof_localusers.lua
>>
>> but starts OK if the conf file says
>>
>> SetupPolicyScript /etc/opendkim/setup_dont_spoof_localusers.lua
>> #ScreenPolicyScript /etc/opendkim/setup_dont_spoof_localusers.lua
>>
>> Why would that be...?!
>
> For one thing, the odkim.internal_ip() function is not available to any
> script other than the setup script. I can't remember why that's so, but
> thats how it is in the current version. I can't think of a good reason to
> leave it that way though. I'll add it to all of them for the next release.
>
> I couldn't get this to segfault with a build of 2.10.3 just now, at least not
> in test mode (i.e., "opendkim -n -x path-to-config"). When you try that, do
> you still get the segmentation fault, or does it have to run and receive a
> message for that to happen?
Well, it happens in test mode as well, opendkim just refuses to start (but
without gaving any hint in the logfile):
# opendkim -n -x /etc/opendkim1.conf
Segmentation fault (core dumped)
when
#SetupPolicyScript /etc/opendkim/setup_dont_spoof_localusers.lua
ScreenPolicyScript /etc/opendkim/setup_dont_spoof_localusers.lua
but it's enough to change the config to
SetupPolicyScript /etc/opendkim/setup_dont_spoof_localusers.lua
#ScreenPolicyScript /etc/opendkim/setup_dont_spoof_localusers.lua
and then it starts OK with the same command, nothing else touched.
If you need any further details about my machine, just let me know. It's
an x86_64 if that should make any difference.
>> b) even when starting OK, as SetupPolicyScript, the script will report "LUA
>> error... NO DOMAINS defined?" in the logfile, as long as I'm trying to use
>>
>> domains_to_sign_for = odkim.get_dbhandle(ctx, DB_DOMAINS);
>
> That returns the set of domains defined by the "Domain" line in your
> configuration file, if you have one.
I do have one. Config file is like
[...]
## Gives the location of a private key to be used for signing ALL messages. This
## directive is ignored if KeyTable is enabled.
KeyFile /etc/opendkim/keys/default.private
## Gives the location of a file mapping key names to signing keys. In simple terms,
## this tells OpenDKIM where to find your keys. If present, overrides any KeyFile
## directive in the configuration file. Requires SigningTable be enabled.
# KeyTable /etc/opendkim/KeyTable
## Defines a table used to select one or more signatures to apply to a message based
## on the address found in the From: header field. In simple terms, this tells
## OpenDKIM how to use your keys. Requires KeyTable be enabled.
# SigningTable refile:/etc/opendkim/SigningTable
----
and
# cat MyDomains
mytestdomain.ro
so it seems that that defined domain just isn't considered for some
reason. No idea so far how I could find out why.
> If you're doing the more modern KeyTable/SigningTable combination, then
> this set will always be empty or not exist.
I'll have to check if that would work. Will report as soon as I figured it
out.
Thank you,
Iosif Fettich
PS. I'd gladly share/contrib the script I'm trying to set up - in our
experience end users are highly scared/disturbed when they get
spam messages 'from themselves'. But as long as I didn't manage to test
the script properly, it makes no sense to 'share'.
On the other hand, although I thought trying to put Lua to work to get
this solved, maybe there are better or easier ways to hit that target.
Opendkim's C code properly detects this situation and issues a warning -
if it would directly allow to say something about how to deal with this in
the config file, there would no need any more to do it in Lua.
Thanks again!
Received on Sat Oct 10 2015 - 11:14:35 PST