Yours is the better answer!DF<div> </div><div> </div><!-- originalMessage --><div>-------- Original message --------</div><div>From: Dotzero <[email protected]> </div><div>Date: 8/13/20 5:54 PM (GMT-05:00) </div><div>To: [email protected] </div><div>Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ? </div><div> </div>On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b) <[email protected]> wrote:
> On Thu, Aug 13, 2020 at 2:33 PM Doug Foster <fosterd= > [email protected]> wrote: > >> The current DMARC architecture supports authorizing a vendor to mail on >> behalf of their clients if the client includes them in their SPF policy or >> delegates a DKIM scope to them and they use it. >> >> >> >> I agree that SPF is too limiting (including hard limits on complexity), >> and DKIM is too complex for an uncooperative vendor. >> >> >> >> In most cases, a solution would be a controlled third-party signature >> authorization along the lines of RFC 6541. >> >> The client would configure the authorization in his own DNS and the and >> the vendor would only need to sign with their own DKIM signature. >> > > If "DKIM is too complex for [this] uncooperative vendor", why would having > the "vendor...sign with...DKIM" be workable? > Wrong answer. If the vendor is uncooperative then fire the vendor. 4-5 years ago it was difficult to find vendors who were willing to deal with DKIM and able to do a good job in implementing. The common mantra was "how does this fit into my business model". These days I would consider it table stakes. Michael Hammer > > _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
