I would prefer that the email gets rejected because it is a malformed email, and this is at a different layer in the SMTP stack.
On 11/9/12 11:32 AM, "Mason Schmitt" <[email protected]> wrote: >> That said, the substitution of RFC5321.MailFrom for an absent >>RFC5322.From >> is a sufficiently common practice that there may be sense in calling >>this >> out in the Security Considerations (that a Mail Receiver which does this >> should also apply the DMARC algorithm as though the synthesised >>RFC5322.From >> header was actually present). > >Yes, that's essentially what I am suggesting. If this became a >standard/suggested configuration for receivers, this would tie up this >particular corner case. > >-- >Mason >_______________________________________________ >dmarc-discuss mailing list >[email protected] >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 [email protected] 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)
