[dmarc-discuss] Multiple SPF results in report

Michiel van de Vis m.vandevis at efuture.nl
Mon Apr 4 23:32:46 PDT 2016


Based on the data we receive at DMARCanalyzer.com we see that the source
for these 'multiple SPF record' reports is mostly Microsoft.

About 98.5% of these records are from Microsoft. The other 1.5% is from
126.com/163.com/yeah.net.

Regards,

Michiel
DMARCanalyzer.com




2016-04-04 19:03 GMT+02:00 Lugo, Dave via dmarc-discuss <
dmarc-discuss at dmarc.org>:

> Thanks, I see a need to familiarize myself with 7208…
>
> --
> Dave Lugo
> Engineer, Comcast Anti-Abuse Technologies
> Desk: 215-286-5451
>
>
> From: Franck Martin <fmartin at linkedin.com>
> Date: Monday, April 4, 2016 at 1:00 PM
> To: Dave Lugo <Dave_Lugo at cable.comcast.com>
> Cc: DMARC Discussion List <dmarc-discuss at dmarc.org>
>
> Subject: Re: [dmarc-discuss] Multiple SPF results in report
>
> The question, is what is the RFC5321.mailfrom is empty? The
> RFC7208.MAILFROM is never empty.
>
> https://tools.ietf.org/html/rfc7208#section-2.4
>
> SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check
>    either has not been performed or has not reached a definitive policy
>    result by applying the check_host() function to the "MAIL FROM"
>    identity as the <sender>.
>
>    [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in
>    [RFC5321] <https://tools.ietf.org/html/rfc5321#section-4.5.5>).  In this case, there is no explicit sender mailbox, and
>    such a message can be assumed to be a notification message from the
>    mail system itself.  When the reverse-path is null, this document
>    defines the "MAIL FROM" identity to be the mailbox composed of the
>    local-part "postmaster" and the "HELO" identity (which might or might
>    not have been checked separately before).
>
>
>
> On Mon, Apr 4, 2016 at 8:59 AM, Lugo, Dave via dmarc-discuss <
> dmarc-discuss at dmarc.org> wrote:
>
>> Franck,
>>
>> What if the RFC7208.MAILFROM is empty?  I recall some questions from
>> colleagues re dmarc reporting and the spf scope (help or mailfrom).
>>
>> Thanks,
>>
>> Dave
>>
>> --
>> Dave Lugo
>> Engineer, Comcast Anti-Abuse Technologies
>> Desk: 215-286-5451
>>
>>
>> From: dmarc-discuss <dmarc-discuss-bounces at dmarc.org> on behalf of
>> Franck Martin via dmarc-discuss <dmarc-discuss at dmarc.org>
>> Reply-To: Franck Martin <fmartin at linkedin.com>
>> Date: Monday, April 4, 2016 at 11:51 AM
>> To: Maarten Oelering <maarten at postmastery.net>
>> Cc: "nick at graafhenk.nl" <nick at graafhenk.nl>, DMARC Discussion List <
>> dmarc-discuss at dmarc.org>
>> Subject: Re: [dmarc-discuss] Multiple SPF results in report
>>
>> It is a bug.
>>
>> There can only be one SPF per record. Theoretically SPF returns 2
>> results, one for the RFC7208.HELO and another one for RFC7208.MAILFROM, but
>> DMARC takes as input only RFC7208.MAILFROM, therefore only this results is
>> needed in DMARC reports.
>>
>> RFC7208.MAILFROM is not RFC5321.MailFrom, there is a subtle but important
>> difference here.
>>
>> On Mon, Apr 4, 2016 at 12:23 AM, Maarten Oelering via dmarc-discuss <
>> dmarc-discuss at dmarc.org> wrote:
>>
>>> Do you mean that in the XML you see 6 <spf> elements in one
>>> <auth_results> element? Or do you mean you see 6 different <spf> domains in
>>> the your reports?
>>>
>>> Maarten Oelering
>>> Postmastery
>>>
>>> On 4 apr. 2016, at 09:05, Nick via dmarc-discuss <
>>> dmarc-discuss at dmarc.org> wrote:
>>>
>>> I received a DMARC report with multiple SPF results. I wonder how this
>>> is possible as I only have one SPF record for my domain defined. In one
>>> report I got 6 SPF results.
>>>
>>> The only thing I could think of is some automatic forwarding service
>>> changing the return path header. Are there more usecases possible how this
>>> can happen?
>>>
>>> Thanks
>>> Nick
>>> _______________________________________________
>>> dmarc-discuss mailing list
>>> dmarc-discuss at dmarc.org
>>> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>>>
>>> NOTE: Participating in this list means you agree to the DMARC Note Well
>>> terms (http://www.dmarc.org/note_well.html)
>>>
>>>
>>>
>>> _______________________________________________
>>> dmarc-discuss mailing list
>>> dmarc-discuss at dmarc.org
>>> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>>>
>>> NOTE: Participating in this list means you agree to the DMARC Note Well
>>> terms (http://www.dmarc.org/note_well.html)
>>>
>>
>>
>> _______________________________________________
>> dmarc-discuss mailing list
>> dmarc-discuss at dmarc.org
>> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>>
>> NOTE: Participating in this list means you agree to the DMARC Note Well
>> terms (http://www.dmarc.org/note_well.html)
>>
>
>
> _______________________________________________
> dmarc-discuss mailing list
> dmarc-discuss at dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
> NOTE: Participating in this list means you agree to the DMARC Note Well
> terms (http://www.dmarc.org/note_well.html)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://dmarc.org/pipermail/dmarc-discuss/attachments/20160405/4f92d228/attachment.html>


More information about the dmarc-discuss mailing list