Re: [dmarc-ietf] Ticket #1 - SPF alignment

Hector Santos <hsantos@isdg.net> Tue, 02 February 2021 16:59 UTC

Return-Path: <hsantos@isdg.net>
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 4C48E3A0C58 for <dmarc@ietfa.amsl.com>; Tue, 2 Feb 2021 08:59:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.146
X-Spam-Level: *
X-Spam-Status: No, score=1.146 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, NICE_REPLY_A=-0.001, PDS_OTHER_BAD_TLD=1.997, SPF_PASS=-0.001, URIBL_ABUSE_SURBL=1.25, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=P/U42xXg; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=dV1pAswh
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 adIdphJaROuk for <dmarc@ietfa.amsl.com>; Tue, 2 Feb 2021 08:59:16 -0800 (PST)
Received: from mail.winserver.com (ftp.catinthebox.net [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C91D3A0C17 for <dmarc@ietf.org>; Tue, 2 Feb 2021 08:59:15 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3540; t=1612285148; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=RXKnJXouru8DkK3LXpE1P5fSNy9G /BBO+VFXttNXPNw=; b=P/U42xXgK6E49NLKGKJ8Uct+3Z2IDTU6pgO4l7NOUXt/ 7SB/XIIo4hc9cyIQcs5dwVZtCQswkg37PvxLTAuSpitKldXCC1xBhOFsI67RTrpb +ZjkEqHSiMbp7BdWAJurFC2+iSimwcsFJcz/ZpCXlYsVt9OnCJltsLZ+Zewi+1Q=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 02 Feb 2021 11:59:08 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 613355729.16691.3852; Tue, 02 Feb 2021 11:59:07 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3540; t=1612285122; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=RXKnJXo uru8DkK3LXpE1P5fSNy9G/BBO+VFXttNXPNw=; b=dV1pAswh9yz3XWenbqsQbK2 MGv9G5RBq1gHzUK95bV7FXe5hkbQlDu+GHxugrSfA3ihvJvTrIaQymVJxPBafyT+ 8XniBO3OH6qwJ9invLIBmXMCk41BqBhRmF+sn/edtsa/oyXE+IrU4Gy7m2eBaXWF PiH4yGVeIT90tH7EB8gs=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 02 Feb 2021 11:58:42 -0500
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1297050346.1.25104; Tue, 02 Feb 2021 11:58:41 -0500
Message-ID: <601984D8.7050304@isdg.net>
Date: Tue, 02 Feb 2021 11:59:04 -0500
From: Hector Santos <hsantos@isdg.net>
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: Alessandro Vesely <vesely@tana.it>, "Murray S. Kucherawy" <superuser@gmail.com>, IETF DMARC WG <dmarc@ietf.org>
CC: 'Hector Santos' <winserver@icloud.com>
References: <bef64e7a-571b-a73f-dc91-aa402ca320c8@taugh.com> <1655426.E2olI3CrJK@zini-1880> <c39916f8-33f5-9876-c018-53085f5cc8f5@tana.it> <3776619.NdRDDhGtae@zini-1880> <81ab38a1-4b0a-3845-fc8c-7d49d7850c26@tana.it> <CAL0qLwZgB4iVSudbJeh8NGiKd1232SBTy4YDG6Zj-=LV+1m6Uw@mail.gmail.com> <fc735412-dfa2-20c8-087f-727b13eb3ad5@tana.it> <CAL0qLwbYxTXXXpx11L3f1CqBns=fSRho3C+S7q=-DmiPSvxKvg@mail.gmail.com> <cf51d6d4-0c7b-971d-bcac-743370f16433@tana.it> <CAL0qLwYK7SFfV5fOb7qhy5hVgR15z4HEJbAHv38OFMAfC=_j-Q@mail.gmail.com> <920ee8e1-2947-379e-5798-2a6818e69526@tana.it>
In-Reply-To: <920ee8e1-2947-379e-5798-2a6818e69526@tana.it>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/YbC9DLoVJ-YG4SyFcWf66HvWDnc>
Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment
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: Tue, 02 Feb 2021 16:59:21 -0000

This is real legit "feasible" proposal so let see where it goes ....

On 1/30/2021 5:41 AM, Alessandro Vesely wrote:>

>> Anyway, I'll let consensus fall where it may.

The solution is to consider the PRA/SUBMITTER protocols which was part 
of the SenderID protocol and many MTA clients already supported:

SUBMITTER https://tools.ietf.org/html/rfc4405
PRA https://tools.ietf.org/html/rfc4407

When the ESMTP Extension SUBMITTER is enabled, the client add can a 
SUBMITTER= parameter to the MAIL FROM. Example of a complete session 
this morning:

C: EHLO oscar.ultrashed.buzz
S: 250-mail.winserver.com, Pleased to meet you.
S: 250-SIZE 10240000
S: 250-8BITMIME
S: 250-SUBMITTER
S: 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
S: 250-AUTH=LOGIN
S: 250-HELP
S: 250 STARTTLS
C: MAIL 
FROM:<27188-46690-410393-7123-hector.santos=santronics.com@mail.ultrashed.buzz> 
BODY=8BITMIME SUBMITTER=Easysheds@ultrashed.buzz
S: 250 
<27188-46690-410393-7123-hector.santos=santronics.com@mail.ultrashed.buzz>zz>... 
Sender validation pending. Continue. (8BITMIME ok)
C: RCPT TO:<hector.santos@santronics.com>
** WCX Process: wcsap ret: 550 (63 msecs) (Rejected by WCSAP RBL Host 
bl.spamcop.net)
S: 550 Return Path not verifiable.
C: QUIT
S: 221 closing connection
** Completed. Elapsed Time: 530 msecs


Our wcSMTP supports the SUBMITTER SMTP Service Extension (RFC4405). 
The keyword SUBMITTER is advertised.  The client uses RFC4407 
Purported Responsible Address (PRA) to extra the PRA which is usually 
the 5322.From address and issues the MAIL FROM:

C: MAIL 
FROM:<27188-46690-410393-7123-hector.santos=santronics.com@mail.ultrashed.buzz> 
BODY=8BITMIME SUBMITTER=Easysheds@ultrashed.buzz

So here we can see the 5322.From is different from the 5321.MailFrom 
return path, a subdomain but different.

My proposal is for the SMTP server to use this opportunity to do a 
DMARC look up for ultratrashed.buzz domain. Lets do this now:

v=DMARC1; p=none; fo=1; rua=mailto:info@ultrashed.buzz; 
ruf=mailto:info@ultrashed.buzz;

And there is no DMARC record for the subdomain.

And note the EHLO subdomain, "oscar" vs "mail" for the return path.

But how does this help?


Well, the receiver now knows the there is a DMARC record and therefore:

1) The message MUST be signed but we won't know this until the payload 
is transferred,

2) SPF is expected. There is no SPF record any of three domains, and

3) The p=none means he doesn't really care if it alignment fails or 
they are not sure but its not reject|quarantine which means they don't 
expect alignment enforcement.

But considering there is DMARC record but no SPF record means there is 
a problem with this transaction. It can be refused probably on that 
basis. But as you can see, it was rejected but for RBL reasons. :-)

We SHOULD consider the two protocols (PRA/SUBMITTER) for DMARC/SPF 
integration. This extra bit of information help at SMTP before the 
potentially high overhead payload is transferred. That was the main 
MS-patented (frivolous) reason for this optimization -- to avoid the 
payload transfer overhead.

But the beauty of this proposal is that it is not new! There are 
clients out there that do support it and will extract the PRA and 
issue it at SMTP MAIL FROM state:

C: MAIL FROM:<return-path> [SUBMITTER=pra]

At the point, the SMTP client has some awareness of the payload and 
DMARC expectations.


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos