Re: [dmarc-ietf] non-mailing list use case for differing header domains

Hannu Aronsson <haa@iki.fi> Sun, 09 August 2020 15:11 UTC

Return-Path: <haa@iki.fi>
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 8DF3F3A098B for <dmarc@ietfa.amsl.com>; Sun, 9 Aug 2020 08:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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=iki.fi
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 MN9S-R9M11fq for <dmarc@ietfa.amsl.com>; Sun, 9 Aug 2020 08:11:36 -0700 (PDT)
Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4E43A0985 for <dmarc@ietf.org>; Sun, 9 Aug 2020 08:11:33 -0700 (PDT)
Received: from [172.20.10.5] (213-216-249-231.bb.dnainternet.fi [213.216.249.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: haa) by meesny.iki.fi (Postfix) with ESMTPSA id 2FA02202B0 for <dmarc@ietf.org>; Sun, 9 Aug 2020 18:11:27 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1596985889; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WOmAt8vKN3nECYgHXfndYpl5VDd8KXjfxpKMqoiM+z0=; b=GnqJUnLZbbccHuJxXQnMJ1DiMRpINTYnsWddpDqW4UZCV51DfYGHXGZ72O5c88fDynpUNh kKq7+LP6MjitZcSJDFSDxASh+MVkWmBSfe3UdqV2woslEUUuN+Im8EbL1FaOEpYevf0qAU h7QvQkjaWk5CZoKOgCbC6LZJ0b2WiBk=
From: Hannu Aronsson <haa@iki.fi>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Sun, 09 Aug 2020 18:11:16 +0300
References: <f82ecb18-0de8-0e36-6b76-7b937399d964@dcrocker.net> <C0FE9C52-8050-41BE-B79C-C905F9C26F93@iki.fi>
To: dmarc@ietf.org
In-Reply-To: <C0FE9C52-8050-41BE-B79C-C905F9C26F93@iki.fi>
Message-Id: <FB6E5DC4-03CF-440B-A760-B676A7850F72@iki.fi>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1596985889; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WOmAt8vKN3nECYgHXfndYpl5VDd8KXjfxpKMqoiM+z0=; b=Lc0XXUwy9ey1rGjP1f98NkoDnGrpTWG+dnXl+9lOleHSajUvZrayrSP9/jnWa2Fy027ct1 ZUJqaL5n3HuNnuNBOESihF9f7Nqvb5f3PMgeeuyPZFZkeTX3w/x0BQ0kZyaO8Nxi1LBFTf ArR+9zpcJpJl/aeqr/1oF4T3ge0XHP4=
ARC-Seal: i=1; s=meesny; d=iki.fi; t=1596985889; a=rsa-sha256; cv=none; b=C++Ul/dYz8ZC0uAd0TRjSaac78pupe76ibvaT5n1zWEc7JKv4a035IMrxE5dd/VQLi7ZjJ 8y4vUtGFXypadc5Z7rT/cSmeg9Fnh/MvbHOjz+mGlYFEUy0MA28hYTnOXNMcYY6mDcjYKL SF8xkvfxU/X6v0l0CX5zQVzXJAvpd44=
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=haa smtp.mailfrom=haa@iki.fi
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/csRNs4sW-RCjp3TtgygSqKPmhsM>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
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: Sun, 09 Aug 2020 15:11:40 -0000

Hello,

Quick correction: As DMARC requires only either DKIM or SPF which I had confused, this removes the need for the proposal point 1). Thanks for the off-list help received.

This seems to be mostly an SPF issue, but still remains when
- SPF used used alone without DMARC (not sure if relevant for this discussion, but it is a real-world problem) and 
- DMARC when DKIM is not used and it falls back to SPF
causing indirect emails to fail, especially with p=reject or -all settings or overly strict receiver deployments. 

For fixing the SPF issue a solution using ARC would be much preferable to the SRS (Sender Rewriting Scheme) workaround, because e.g. the messages would be unchanged, avoid problems with long email addresses or requiring databases, and DMARC strict From alignment issues, etc.

The other topics in the email, 
- forwarding use cases from M3AAWG discussions and 
- figuring out how we could get ARC reputation solution in place
are hopefully still interesting for this discussion.

Yours,
  Hannu

> On 9.8.2020, at 13:28+0300, Hannu Aronsson <haa@iki.fi> wrote:
> 
> Hello,
> 
> I have been lurking here around for a while and we have been working at M3AAWG for some time as well.
> 
> Today’s DMARC is breaking more and more email as it gets more widely and often overly strictly deployed.
> 
> I feel the major issue with DMARC is email forwarding in it’s many forms, in addition to mailing list issues. It would be preferable to try to do something that helps email survive as an open platform instead of bad workarounds. 
> 
> Transactional and person-to-person emails also should work reliably with DMARC (and similar things) when forwarded i.e. indirect delivery.
> 
> 
> In M3AAWG discussions, we have identified many stakeholders who are seeing major issues with DMARC and SPF when forwarding email for various valid reasons, examples:
> 
> a) ISPs hosting user domains and email from to addresses in those domains is forwarded to external mailbox addresses. This is very common for smaller organizations.
> 
> b) Alumni and organization member addresses like alumni.harvard.edu, acm.org, iki.fi and many others that provide a “permanent” email address and forward email to user-specified mailbox provider addresses.
> 
> c) Users forwarding email themselves to another email address e.g. based on rules or forwarding to their mobile device address, or forwarding old ISP email to new ISP, etc.
> 
> d) Some mailing lists and smaller email distributions, too, which work just forward messages as they are to their members.
> 
> e) and of course the many users using these services, and senders trying to send to them.
> 
> So there may be many more stakeholders with DMARC issues than one might initially think about. DMARC is creating a lot of “the message did not get thru” issues for valid and real emails these days.
> 
> To be worth pushing further, DMARC needs to be compatible with with email forwarding i.e. indirect mail flows.
> 
> 
> To try to clarify my thinking around this, I tried to put some thoughts into a practical proposal format so it would be easier to consider, comment and discuss and think about the practicalities around it.
> 
> Based on the discussion, it seems it might be more practical to try to make “small” improvements into DMARC. If we can find some useful way forward, we’re willing to work on an internet-draft for more formal commenting.
> 
> Background, in addition to the use cases above:
> 
> Because SPF fails with forwarded/indirect emails, and as DMARC today depends on SPF, it also fails in these use cases, especially when deployed overly strictly.
> 
> Normal email forwarding does not break DKIM as the messages are not changed. We have new tools available today that can help, specifically ARC.
> 
> We should aim to make DMARC compatible with these forwarding use cases, without losing the anti-abuse aims if possible.
> 
> Draft proposal for comments: 
> 
> When a DMARC recipient MTA is processing an incoming message,
> 
> 1) If DKIM is valid, SPF results should be ignored. DKIM already proves the message is from the source it claims to be from, it doesn’t matter if it arrived via an indirect path.
> 
> 2) If DKIM is not used, but ARC is used, SPF processing should walk the ARC header chain as long as they have acceptable reputation and if a matching IP address is found there, consider the SPF check successful.
> 
> 3) If DKIM and ARC are not used and SPF/DMARC fails, you could act as today, or probably we should recommend always putting failing messages somewhere where the user can search for the “lost messages” when needed, e.g. to the junk mailbox or quarantine.
> 
> If something like this was in place, forwarders and others would be highly motivated to implement ARC, helping senders and recipients who want to deploy DMARC or DMARC-like solutions.
> 
> ARC reputation:
> 
> ARC reputation has been discussed a lot and may be a major roadblock in going this way. I think the situation has changed now as DMARC issues become larger and affect more users, so people are more ready to do something about it now.
> 
> * Technically we should be able to simply use DNS-based IP allowlists to get reputation information for the ARC signing intermediaries.
> 
> * ARC allowlisting would allows MTA admins to choose suitable allowlists from free and paid options from various sources and vendors, just like they use blocklists today for email already. 
> 
> * We could probably even re-use existing email RBL allow/blocklists for this purpose, if you don’t trust some IP reputation as sender, you would not trust it for ARC either.
> 
> * Free options would be available so DMARC2 software and solutions could include default settings that already work out of the box for smaller organizations.  
> 
> * It seems possible to maintain semi-manual lists of “major trusted” forwarding services and have a suitable vetting process for that. At iki.fi we have looked at doing something like this, if it would help.
> 
> * Additionally people would offer various automated lists based on other analysis and methods.
> 
> * ARC reputation could at this time have become an additional service for email protection vendors to sell. Maybe before this was not viable earlier because ARC was not widely available yet, or the SPF/DMARC issue was not severe enough before?
> 
> * Mailbox service admins could add “trusted forwarding IPs” locally to help specific users with forwarding related issues. Today there doesn’t seem to be an easy options for mailbox service providers to help their users who have SPF/DMARC issues.
> 
> Yours,
>   Hannu
> -- 
> Hannu Aronsson
> haa@iki.fi
> 
>> Dave Crocker <dhc@dcrocker.net> wrote 8.8.2020 5.37:
>> 
>> I suspect the calculus is less in the pragmatic terms of asking how big this threat is and more in terms of wishing for some version of protection and thinking this helps to achieve it.
>> 
>> The degree to which so many folk embrace does not appear to have that much empirical basis, but rather a sense of feeling a need to do something and at first blush this seems to be something.


--
haa@iki.fi https://www.haa.iki.fi