----- Original Message -----
> From: "Raman Gupta" <rocketra...@gmail.com>
> To: dmarc@ietf.org
> Cc: "Franck Martin" <fra...@peachymango.org>, "Murray S. Kucherawy"
> <superu...@gmail.com>
> 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
>
> On 12/01/2013 04:36 PM, Franck Martin wrote:
> > Murray,
> >
> > Raman was talking when the return-path is empty like for bounces.
>
> Right.
>
> > 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?
>
> 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?
>
Yes. I see plenty fake bounces with attack payload in them.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
