Subject: Re: [dmarc-ietf] Suggestion: handle null reverse path SPF alignment with RFC5322.From in different domain

From: Franck Martin <[email-masked]>
Date: Sun, 1 Dec 2013 13:36:44 -0800

Murray,

Raman was talking when the return-path is empty like for bounces.

DMARC follows SPF and uses for alignment whatever SPF used to give a result. So when there is a return path, this is the domain in the return-path (envelope from) otherwise when the return-path is empty this is the domain in the helo/ehlo.

From the text below from Raman, which describes the way DMARC works accurately, I'm not sure what alternate behavior DMARC should have?

May be the issue is: "The host in bar.com is a valid SPF sender for domain foo.com". However I have no idea how you can infer this statement programatically. There is no DNS record today that allows you to infer it (?).

On Nov 30, 2013, at 10:39 PM, Murray S. Kucherawy <[email-masked]> wrote:

> Any other input on this point?  DMARC currently only considers the SPF result if there is alignment between the return path and the From field.
> 
> 
> On Mon, Sep 2, 2013 at 3:42 PM, Raman Gupta <[email-masked]> wrote:
> I encountered a use case recently with an auto-generated email with
> RFC5322.From domain foo.com, sent from a host in domain bar.com.
> Because the email was auto-generated by sieve, it contained a null
> return path. The host in bar.com is a valid SPF sender for domain foo.com.
> 
> DMARC failed the SPF check despite the valid SPF, since the
> RFC5322.From address was not aligned with the domain bar.com extracted
> from the HELO/EHLO.
> 
> A valid way to circumvent this problem is to use DKIM signing, aligned
> with foo.com, in which case DMARC is designed to ignore the SPF
> failure and pass overall.
> 
> However, I do think this is a valid situation which the SPF alignment
> rules should consider.
> 
> I hope I have explained this sufficiently. Thank you to Steven Jones
> and Scott Kitterman and others on the dmarc-discuss list for
> clarifying the situation presented here.
> 
> Regards,
> Raman Gupta
> Principal
> VIVO Systems
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
> 
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 Dec 2013 19:35:15 -0800

I understood what he was saying; my issue was with my mis-remembering of
what DMARC does with SPF.  For some reason I was remembering that only an
SPF check against the envelope sender mattered.  I must've been
decaffeinated.

Regardless, I agree that I don't know what algorithm, short of a heuristic
or something more liberal, could be used to match foo.com and bar.com in
the example.  The more liberal the matching is, the easier we open up an
abuse vector.  If this does become a pain point, we could adopt something
like ATPS, but that's only something this group should consider if there's
plenty of evidence that it's necessary.

-MSK

On Sun, Dec 1, 2013 at 1:36 PM, Franck Martin <[email-masked]>wrote:

> DMARC follows SPF and uses for alignment whatever SPF used to give a
> result. So when there is a return path, this is the domain in the
> return-path (envelope from) otherwise when the return-path is empty this is
> the domain in the helo/ehlo.
>
> From the text below from Raman, which describes the way DMARC works
> accurately, I'm not sure what alternate behavior DMARC should have?
>
> May be the issue is: "The host in bar.com is a valid SPF sender for
> domain foo.com". However I have no idea how you can infer this statement
> programatically. There is no DNS record today that allows you to infer it
> (?).
>
> Any other input on this point?  DMARC currently only considers the SPF
> result if there is alignment between the return path and the From field.
>
>

---

From: Raman Gupta <[email-masked]>
Date: Tue, 03 Dec 2013 12:50:13 -0500

> Raman was talking when the return-path is empty like for bounces.

Right.

> return-path (envelope from) otherwise when the return-path is empty
> this is the domain in the helo/ehlo.
>

The alternate behavior could be: DMARC alignment rules for
RFC5322.From would apply when there is an RFC521.MailFrom address
available. Otherwise, DMARC falls back to the regular DKIM and/or SPF
identification rules.

See below.

> May be the issue is: "The host in bar.com <http://bar.com> is a valid
> SPF sender for domain foo.com". However I have no idea how you can
> infer this statement programatically. There is no DNS record today
> that allows you to infer it (?).

I may have stated the initial situation slightly incorrectly. I should
have said: the evaluation of the SPF record linked to the HELO/EHLO
FQDN was valid. See, for example:

http://www.openspf.org/FAQ/Common_mistakes#helo

In this case, the SPF evaluation based on the HELO/EHLO identification
and linked record is that the email is valid, but the extra DMARC
alignment rules cause a DMARC failure, since the HELO/EHLO domain does
not match the RFC5322.From domain.

If there was no DMARC RFC5322.From alignment rule against the SPF
HELO/EHLO identification in this case, is there a new abuse vector?

Regards,
Raman

> On Nov 30, 2013, at 10:39 PM, Murray S. Kucherawy <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>> Any other input on this point?  DMARC currently only considers the
>> SPF result if there is alignment between the return path and the
>> From field.
>>
>>
>> On Mon, Sep 2, 2013 at 3:42 PM, Raman Gupta <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> I encountered a use case recently with an auto-generated email
>> with RFC5322.From domain foo.com <http://foo.com/>, sent from a
>> host in domain bar.com <http://bar.com/>. Because the email was
>> auto-generated by sieve, it contained a null return path. The
>> host in bar.com <http://bar.com/> is a valid SPF sender for
>> domain foo.com <http://foo.com/>.
>> 
>> RFC5322.From address was not aligned with the domain bar.com 
>> <http://bar.com/> extracted from the HELO/EHLO.
>> 
>> A valid way to circumvent this problem is to use DKIM signing, 
>> aligned with foo.com <http://foo.com/>, in which case DMARC is
>> designed to ignore the SPF failure and pass overall.
>> 
>> However, I do think this is a valid situation which the SPF 
>> alignment rules should consider.
>> 
>> I hope I have explained this sufficiently. Thank you to Steven
>> Jones and Scott Kitterman and others on the dmarc-discuss list
>> for clarifying the situation presented here.
>>
>> Regards,
>> Raman Gupta
>> Principal
>> VIVO Systems
>> [email-masked] <mailto:[email-masked]>

---

From: Franck Martin <[email-masked]>
Date: Tue, 3 Dec 2013 12:20:40 -0600 (CST)

----- Original Message -----
> From: "Raman Gupta" <[email-masked]>
> To: [email-masked]
> Cc: "Franck Martin" <[email-masked]>, "Murray S. Kucherawy" <[email-masked]>
> Sent: Tuesday, December 3, 2013 9:50:13 AM
> Subject: Re: [dmarc-ietf] Suggestion: handle null reverse path SPF alignment with RFC5322.From in different domain
> 

Yes. I see plenty fake bounces with attack payload in them.

---

From: Raman Gupta <[email-masked]>
Date: Tue, 03 Dec 2013 13:27:46 -0500

> Yes. I see plenty fake bounces with attack payload in them.

And the fake bounces have a valid SPF?

Regards,
Raman

---

From: Franck Martin <[email-masked]>
Date: Tue, 3 Dec 2013 17:51:16 -0600 (CST)

----- Original Message -----
> To: "Franck Martin" <[email-masked]>
> Cc: [email-masked], "Murray S. Kucherawy" <[email-masked]>
> Sent: Tuesday, December 3, 2013 10:27:46 AM
Considering that many people forgets to put a SPF record on the hostname pointed by the helo, no, but this would not stop spammers to adopt SPF if that gives them an edge.