[opendmarc-dev] 1.2.1 Beta2 available

[Todd Lyons]

Another interesting bit of info.  With the option to add the job id to
the authservid:

Apr  1 05:11:57 lunar opendmarc[6130]: trusted authentication
services: lunar.ivenue.com
<snip>
Apr  1 05:16:03 lunar opendmarc[6130]: s31CFlbY006346 ignoring
Authentication-Results at 6
 from medusa.blackops.org
Apr  1 05:16:03 lunar opendmarc[6130]: s31CFlbY006346 ignoring
Authentication-Results at 8 from medusa.blackops.org
Apr  1 05:16:03 lunar opendmarc[6130]: s31CFlbY006346 ignoring
Authentication-Results at 11 from medusa.blackops.org
Apr  1 05:16:03 lunar opendmarc[6130]: s31CFlbY006346 ignoring
Authentication-Results at 14 from medusa.blackops.org
Apr  1 05:16:03 lunar opendmarc[6130]: s31CFlbY006346 ignoring
Authentication-Results at 16 from lunar.ivenue.com/s31CEkcO006253

So it didn't know to exclude the /JOBID part?

I don't have any results with this option disabled (default) yet
because it was dying on inbound emails before it got to this point.  I
will watch the logs for it.  This email to the list should trigger the
section of code, as the above was from the list message I had just
sent.

...Todd


On Tue, Apr 1, 2014 at 5:14 AM, Todd Lyons <tlyons at ivenue.com> wrote:
> Ok, that didn't take long:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ffff6035940 (LWP 5506)]
> dmarcf_match (str=0x7ffff6011a54 "medusa.blackops.org", array=0x0, icase=false)
>     at opendmarc.c:812
> 812             for (c = 0; array[c] != NULL; c++)
> (gdb) where
> #0  dmarcf_match (str=0x7ffff6011a54 "medusa.blackops.org", array=0x0,
> icase=false)
>     at opendmarc.c:812
> #1  0x0000000000406499 in mlfi_eom (ctx=0x61a9a0) at opendmarc.c:2135
> #2  0x000000000040fb48 in st_bodyend ()
> #3  0x000000000040ff32 in mi_engine ()
> #4  0x000000000040d698 in mi_handle_session ()
> #5  0x000000000040c389 in mi_thread_handle_wrapper ()
> #6  0x00007ffff75a183d in start_thread () from /lib64/libpthread.so.0
> #7  0x00007ffff7317fad in clone () from /lib64/libc.so.6
> (gdb) print c
> $1 = <value optimized out>
> (gdb) print *array
> Cannot access memory at address 0x0
> (gdb) print *str
> $2 = 109 'm'
> (gdb) print str
> $3 = 0x7ffff6011a54 "medusa.blackops.org"
> (gdb) print array
> $4 = (char **) 0x0
> (gdb) print icase
> $5 = false
>
> (gdb) up
> #1  0x0000000000406499 in mlfi_eom (ctx=0x61a9a0) at opendmarc.c:2135
> 2135                    if (strcasecmp(ar.ares_host, authservid) != 0 &&
> (gdb) print conf
> $6 = (struct dmarcf_config *) 0x61a010
> (gdb) print *conf
> $7 = {conf_reqhdrs = false, conf_afrf = false, conf_afrfnone = false,
>   conf_rejectfail = false, conf_dolog = false, conf_enablecores = true,
>   conf_addswhdr = false, conf_authservidwithjobid = false,
> conf_recordall = false,
>   conf_refcnt = 3, conf_dnstimeout = 0, conf_data = 0x61a3b0, conf_afrfas = 0x0,
>   conf_afrfbcc = 0x0, conf_copyfailsto = 0x0,
>   conf_reportcmd = 0x411538 "/usr/sbin/sendmail -t -odq", conf_tmpdir = 0x0,
>   conf_authservid = 0x0, conf_historyfile = 0x61a330
> "/var/run/opendmarc/opendmarc.dat",
>   conf_pslist = 0x0, conf_ignorelist = 0x0, conf_trustedauthservids = 0x0,
>   conf_ignoredomains = 0x0}
> (gdb)
>
> I guess the big issue here is that opendmarc at various points is
> making assumptions that something is set for authservid in the config
> file.  I have never had to set this before, it has always worked by
> figuring out its name from DNS.  If setting the authservid is now a
> requirement, maybe consider altering opendmarc to fail to start if the
> parameter is not set.  I don't know how many other places it's
> referenced, but they all need to check if conf->authservid is not null
> before trying to access anything in it.
>
> Temporarily, I have set in my config:
> AuthservID HOSTNAME
> which, according to the config file, will cause it to use the DNS
> hostname, same as the old default.
>
> ...Todd
>
> On Tue, Apr 1, 2014 at 5:03 AM, Todd Lyons <tlyons at ivenue.com> wrote:
>> However, since moving up to the 1.2.x series, I'm getting constant
>> restarts, and nothing is in the logs.  It goes from working and
>> logging normally to sendmail being unable to communicate with it.
>> I've started a foreground instance of the daemon under gdb to see if I
>> can figure out why it's doing it.
>>
>> ...Todd
>>
>>
>> On Mon, Mar 31, 2014 at 1:40 PM, Todd Lyons <tlyons at ivenue.com> wrote:
>>> Looks good here.
>>>
>>> ...Todd
>>>
>>> On Sun, Mar 30, 2014 at 10:56 PM, Murray S. Kucherawy <msk at blackops.org> wrote:
>>>> The only change in this tarball is a further fix to the authserv-id crash
>>>> and aesthetic issues previously reported.
>>>>
>>>> -MSK
>>>>
>>>> _______________________________________________
>>>> opendmarc-dev mailing list
>>>> opendmarc-dev at trusteddomain.org
>>>> http://www.trusteddomain.org/mailman/listinfo/opendmarc-dev
>>>
>>>
>>>
>>> --
>>> 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
>>
>>
>>
>> --
>> 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
>
>
>
> --
> 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



-- 
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