Consider two names: [email protected], where "fake.bank" is non-existent. "promotions.fake.bank" is therefore also non-existent. and [email protected], where "real.bank" exists, but "promotions.real.bank" does not exist.
We can assume that the marketing department made up the "promotions.real.bank" name and then hired sendgrid.net or constantcontact.net to do a mass mailing for them. The mailing is DKIM signed with a "real.bank" signature. To complete the example, we assume that "real.bank" has not yet published a DMARC policy, so the PSD policy applies. When the PSD policy is operational, my argument is that the only thing that matters is whether the domain exists, not whether the RFC5322.From address exists. In my logic, "[email protected]" is exempt from the PSD NP policy because the organization exists, and is DMARC PASS if the PSD policy allows relaxed alignment. Under the current text, the message from "[email protected]" must be blocked because the RFC5322.From address does not exist, even though it passes relaxed alignment. Doug On Thu, Aug 4, 2022 at 9:58 PM Murray S. Kucherawy <[email protected]> wrote: > On Thu, Aug 4, 2022 at 10:56 AM Todd Herr <todd.herr= > [email protected]> wrote: > >> I'm struggling to understand what you're trying to say here. >> >> Below is section 4.7 from >> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-15.txt. Can >> you please highlight the specific text you're taking issue with and help me >> understand how it maps to what you've written above? >> [...] >> > > Or in the alternative, maybe an example of the concern in either a real or > made-up DNS tree might illustrate what's going on here. > > -MSK > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
