Subject: [dmarc-ietf] Firing the vendor

From: "Douglas E. Foster" <[email-masked]>
Date: Thu, 13 Aug 2020 18:09:20 -0400

Yours is the better answer!DF<div>
</div><div>
</div><!-- originalMessage --><div>-------- Original message 
--------</div><div>From: Dotzero <[email-masked]> </div><div>Date: 
8/13/20  5:54 PM  (GMT-05:00) </div><div>To: [email-masked] 
</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-masked]> 
wrote:

> On Thu, Aug 13, 2020 at 2:33 PM Doug Foster <fosterd=
> [email-masked]> 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-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Neil Anuskiewicz <[email-masked]>
Date: Thu, 13 Aug 2020 23:01:02 -0700

> On Aug 13, 2020, at 3:09 PM, Douglas E. Foster <fosterd=[email-masked]> wrote:
> 
> 
> Yours is the better answer!
> 
> DF
> 
> 
> -------- Original message --------
> From: Dotzero <[email-masked]>
> Date: 8/13/20 5:54 PM (GMT-05:00)
> To: [email-masked]
> Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
> 
> 
> 
>> On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b) <[email-masked]> wrote:
>>> On Thu, Aug 13, 2020 at 2:33 PM Doug Foster <fosterd=[email-masked]> 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.   
>>> 
>> 
How would this resolve the alignment failures with regard to the RFC5321.from (SPF from) with the organizational domain? 

And I think the vendors motivation is not putting dev and support resources. Does this delegation scheme solve that problem? 

>> If "DKIM is too complex for [this] uncooperative vendor", why would having the "vendor...sign with...DKIM" be workable?
The vendors for whom it would would work already make getting DKIM signing set up easy so there’s no problem to be solved.

For the others there’s not much incentive to devote resources and not much risk to the vendor to mitigate. No incentive and little risk means not on radar unless you care about doing things right. Inbox providers could up the anti more and there’s been some movement in that area. 
> 
> 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.
I see your point but the vast majority of customers Of said vendors  aren’t aware there’s a problem until there is. But make authentication and alignment easy and part of setup as the best vendors do puts people on the right path without hassles, barriers and disincentives.

Fire the vendor isn’t always that easy if you’re locked in and you’ve got shit to do. We’re talking about stone masons, accountants, non profit organizations, home inspectors, SaaS companies, and all the other people who have stuff to get done. 

Yeah, I’ve helped clients fire plenty of vendors but I’m just saying it is not first on one’s to do list most days.

---

From: Dotzero <[email-masked]>
Date: Fri, 14 Aug 2020 04:38:35 -0400

On Fri, Aug 14, 2020 at 2:01 AM Neil Anuskiewicz <[email-masked]>
wrote:

<SNIP>

> does this fit into my business model". These days I would consider it table
> stakes.
>
> I see your point but the vast majority of customers Of said vendors
>  aren’t aware there’s a problem until there is. But make authentication and
> alignment easy and part of setup as the best vendors do puts people on the
> right path without hassles, barriers and disincentives.
>

This is NOT an interoperability issue that needs to be solved by the IETF.
It's a personal problem between a client and their vendor.

>
> Fire the vendor isn’t always that easy if you’re locked in and you’ve got
> shit to do. We’re talking about stone masons, accountants, non profit
> organizations, home inspectors, SaaS companies, and all the other people
> who have stuff to get done.
>

Perhaps the IETF needs to come up with an RFC for people who are locked in
and have shit to do. On the other hand, thst may not fall into the realm of
technical problems that the IETF deals with.

> not first on one’s to do list most days.

And that may be why clients who hire such vendors feel pain, not just with
email authentication but with a whole raft of other issues. A vendor
problem != something that the IETF is going to fix with an RFC.

Michael Hammer