[opendmarc-dev] 1.2.1 Beta2 available

Todd Lyons tlyons at ivenue.com
Tue Apr 1 05:36:14 PDT 2014 

Confirmed, when the job id is added to the authservid, it affects the
parsing of the email.

My server processing an email from the list with the job id added:

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

And my server processing an email from the list with the default
setting of not adding the job id:

Apr  1 05:26:25 lunar opendmarc[6418]: s31CQ933007092 ignoring
Authentication-Results at 6 from medusa.blackops.org
Apr  1 05:26:25 lunar opendmarc[6418]: s31CQ933007092 ignoring
Authentication-Results at 8 from medusa.blackops.org
Apr  1 05:26:25 lunar opendmarc[6418]: s31CQ933007092 ignoring
Authentication-Results at 11 from medusa.blackops.org
Apr  1 05:26:25 lunar opendmarc[6418]: s31CQ933007092 ignoring
Authentication-Results at 14 from medusa.blackops.org

Created a bug for it: https://sourceforge.net/p/opendmarc/tickets/76/

...Todd

On Tue, Apr 1, 2014 at 5:24 AM, Todd Lyons <tlyons at ivenue.com> wrote:
> 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



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

More information about the opendmarc-dev mailing list