Re: [dmarc-ietf] Firing the vendor

Neil Anuskiewicz <neil@marmot-tech.com> Fri, 14 August 2020 06:01 UTC

Return-Path: <neil@marmot-tech.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A903A0D78 for <dmarc@ietfa.amsl.com>; Thu, 13 Aug 2020 23:01:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=marmot-tech.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UOm90JAsNkA for <dmarc@ietfa.amsl.com>; Thu, 13 Aug 2020 23:01:05 -0700 (PDT)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A22C3A0DAD for <dmarc@ietf.org>; Thu, 13 Aug 2020 23:01:05 -0700 (PDT)
Received: by mail-pj1-x102f.google.com with SMTP id mw10so3887157pjb.2 for <dmarc@ietf.org>; Thu, 13 Aug 2020 23:01:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marmot-tech.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=EqG2LYHwroc9wVav/C6LZV+vJ47jRG2Clz+4lCwEKsI=; b=hTCSkCB5piAwoiIyPW/ZxuK48DO5NparlzxO3oKNwDorDHxRUUf9aiU+LSuKCJRZtH atWANJ89cvuGvbppUuJZzXzbVIjfoJXxi8Nd83szyV2kkLsN/cAsIQqi08+s4moR3mY9 4AsEkE4dwHDGsr7a/f9Q4SbfriflW+vVKnQ6U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=EqG2LYHwroc9wVav/C6LZV+vJ47jRG2Clz+4lCwEKsI=; b=Ob2prsts0HlOaLutODdjssX9QrnzlBJ0WbfwJOr4AATlcZG63T+qL0kwW3J4zNIzN2 2Ilva2W11LUDP/sWLeXMweKwJ2hZe+1wUGbb0KmdPwWaC9FAlZPCj55qAZuKlX1wbQu+ pDlnfpOX5M2XZ8CCXeA/J6uhfA9os6qmr/kTGJBKLFrT9GdhR2p83lriSMlQUz90RzIG 5/HtGTGrVoqvmKzaJrp1SmdSza/diNwQqzeUCLznNywLItnosgT1JGAOXmF65xqdkP1A K5K8slHWJF6ukMt2fz1YUoCop2qAIryr0yqbDAC6da4POubayOX1QhAoEvzJ5oq9vCnQ 9GXA==
X-Gm-Message-State: AOAM5325+RPam6KpOihjHTScyxojybzshF7kL64YvCsRqN6ee9YlcPGE ixi9Nvl2g3CvS9vXnuu9LVZxl8mQyoyp8fmL
X-Google-Smtp-Source: ABdhPJxGMvelAQzCOoOg0nvCZ05rKqMpUaoktqBH22/F8PmQN9p593ghweLgBpeHe9In/L0ctpoWxQ==
X-Received: by 2002:a17:902:bc85:: with SMTP id bb5mr927613plb.54.1597384863967; Thu, 13 Aug 2020 23:01:03 -0700 (PDT)
Received: from ?IPv6:2601:1c0:cb00:7680:7ca1:3eb5:41ea:2a35? ([2601:1c0:cb00:7680:7ca1:3eb5:41ea:2a35]) by smtp.gmail.com with ESMTPSA id m29sm7185864pgc.55.2020.08.13.23.01.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Aug 2020 23:01:03 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-21E184DC-1BE6-4EB2-A758-A444D2644E81"
Content-Transfer-Encoding: 7bit
From: Neil Anuskiewicz <neil@marmot-tech.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 13 Aug 2020 23:01:02 -0700
Message-Id: <61A742FF-DBBE-4B22-AA88-8F0E5779CEDB@marmot-tech.com>
References: <291fe9b1380249bbb13bbd77234c788d@com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
In-Reply-To: <291fe9b1380249bbb13bbd77234c788d@com>
To: "Douglas E. Foster" <fosterd=40bayviewphysicians.com@dmarc.ietf.org>
X-Mailer: iPad Mail (17G68)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/j0hP0FCHoMVjDRzuh6u1usgg2bU>
Subject: Re: [dmarc-ietf] Firing the vendor
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Aug 2020 06:01:17 -0000


> On Aug 13, 2020, at 3:09 PM, Douglas E. Foster <fosterd=40bayviewphysicians.com@dmarc.ietf.org> wrote:
> 
> 
> Yours is the better answer!
> 
> DF
> 
> 
> -------- Original message --------
> From: Dotzero <dotzero@gmail.com>
> Date: 8/13/20 5:54 PM (GMT-05:00)
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
> 
> 
> 
>> On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b) <kboth@drkurt.com> wrote:
>>> On Thu, Aug 13, 2020 at 2:33 PM Doug Foster <fosterd=40bayviewphysicians.com@dmarc.ietf.org> 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.