[opendmarc-dev] rfc: how to fix wrong spf result if Received-SPF is used?

[A. Schulze]

Am 17.10.2016 um 20:54 schrieb Juri Haberland:
> On 17.10.2016 11:39, Juri Haberland wrote:
>> I found a bug in the code that uses the result from parsing a Received-SPF
>> header and a general problem in the result codes from the internal SPF
>> checking.
> 
>> Now to the possible fixes:
>> 1) Change the functions that parses the Received-SPF header
>> (dmarcf_parse_received_spf()) and the function that calls libspf2
>> (opendmarc_spf2_test()) to return the real SPF result by using ARES_RESULT_*
>> and flatten it before storing it into the internal DMARC context.
>> Disadvantage:
>>   We have to change the signature (or at least the return values) of a
>> function in the libopendmarc.
>>
>> 2) We enhance the DMARC_POLICY_SPF_OUTCOME_* macros to be able to represent
>> all SPF results, let dmarcf_parse_received_spf() and opendmarc_spf2_test()
>> return these enhanced values, let opendmarc_policy_store_spf() flatten the
>> result itself and map the result to ARES_RESULT_* before writing it to the
>> history file and the internal message context.
>> Advantage:
>>   The library functions would keep their return values, but might return
>> additional values.
>>
>> What solution would you prefer?
> 
> After talking to a colleague, I'll go for option 3:
> Essentially like 1), but move the code from opendmarc_spf2_test() to a new
> function and implement opendmarc_spf2_test() as a wrapper around the new
> function with mapping and flattening from ARES_RESULT_* to
> DMARC_POLICY_SPF_OUTCOME_*. This way the interface of libopendmarc doesn't
> change except that there is a new function.
> 
>   Juri

Juri,

I guess there are not many subscribers on -dev able to follow you.
At least it's far beyond /my/ skills. Sorry: I couldn't give technical advise.
But I like to ask a question: Do you think you're able to also extend the test subsystem?
If there would be a unit-test I would feel best with your suggestion #3.

Andreas