> -----Original Message----- > From: dmarc [mailto:[email protected]] On Behalf Of Steve Atkins > Sent: Wednesday, April 01, 2015 11:56 AM > To: [email protected] > Subject: Re: [dmarc-ietf] Third Party Sender DMARC Adaptations > > > > > On Apr 1, 2015, at 08:31, Dave Crocker <[email protected]> wrote: > > > >> On 4/1/2015 8:27 AM, Steve Atkins wrote: > >> n the context of reduced SPF and DKIM functionality as required for use > with DMARC, sure. > > > > Wasn't that that was the context of the thread? > > The message being discussed wasn't from a domain that was using DMARC, > though that's usually an implicit context on a dmarc mailing list. > > > > > And one of the useful things about the wording I suggested is that it > > doesn't rely on context. It's always accurate and precise and clear. > > It's clear, but I don't think it's accurate unless you include the context of > DMARC alignment. > > Controlling the domain used in the 5322.from doesn't allow me to do SPF or > dkim authentication, as they don't key off that domain. > > To be able to authenticate I need to control the domain used in the return > path or dkim d= - just controlling the 5322.from itself doesn't allow me to > send authenticated mail using that domain. > > As a concrete example, if I send mail with a 5322.from of [email protected] > through a typical small esp that uses a bounce.esp.com return path and signs > with d=esp.com then I cannot authenticate that email, despite having full > control over the domain used in the 5322.from. >
That's an operational choice Steve. You could provide them a private DKIM key so they could sign d= with your 5322.from domain signature. If they aren't willing to do that and you are concerned about abuse of your domain then you find another vendor. Places you have a contractual relationship with are much easier to resolve than random 3rd parties. Mike _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
