Re: [dmarc-ietf] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03

Rifaat Shekh-Yusef <> Sun, 04 November 2018 21:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D985A128CB7; Sun, 4 Nov 2018 13:59:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QflhxqCHAnWi; Sun, 4 Nov 2018 13:59:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD66E12872C; Sun, 4 Nov 2018 13:59:11 -0800 (PST)
Received: by with SMTP id t81-v6so5111634iod.10; Sun, 04 Nov 2018 13:59:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f+ecuFMWRqVUOfuBbol6fy+m4+0O4eX7+zBR8z5ZRz0=; b=KDz1euOk8M0blDuE8gOgfrsuBxLPazMim59EUkkyYIHM59xWBplHjHu6n60FDQmfHp cvH8JEQJOlJL1jX6KGt1k1XyyGwoBGLYMu7T8a9W89XvlqgQ/zgs9F/ZWjViNxpTBlIA 6cZ6gYsSaNwRYquZsXtHlZGqlmHnL6DKZCqSqAdIVx0at9AQ5WIwnmP3nwLdoGAXqk1w GBmtAt7fv7wd9N8xKLXG27nVXqZ8nrlgxFmBLNT9+lnavNzL0UY6Im+2cTnW7cbGuEkU WfqQD6ablT9zgaE3im/qg/Mzrv/Y+iRmceAwzDzl7bmfNoYyoMqaRsJ0K3rHlLZG5AH0 ooQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f+ecuFMWRqVUOfuBbol6fy+m4+0O4eX7+zBR8z5ZRz0=; b=swrizmZtrj5hbAWRRne08HLp3TC5ETHD8ARwcpEx0rHkgnVhXtjmrfuzr3l2s9qgrS bxyYQBbtPUjY6OgOqFr5roJ6Zub1+kFS947UzqMfvL0bHVt2I2sGDXeEiLZchDzfNZKX HiVTQw7DnTGp1mmys+iHZ5+PikFj/AkT+rwRo7ijjjvXGjjDwVrv2Dicj/bcDBLeRUiz sGHWDg6IfAz8hNoVW3AlTSljhJJZuKn1PVeLhBtk/GGJHKllzCgCt/5E6DrVHQ7wGDgg /Mg03bF7LBSd5EWWytZdf54rqnO/gIGSnf1qr/6nUBwcV8WgWA2fOzrT7QuFpPXWdJAK ilQg==
X-Gm-Message-State: AGRZ1gLTkzlu3eRIkGfvuknpxCPUqa/opDpwAgIBmswBCrHav0oMFIuw 51yMNWxBlXQqichxWNcuxeGLtrWf11n95raFYYA=
X-Google-Smtp-Source: AJdET5fLp9HD5ATnPratuMl/Ee9W1PC4QWfQhfm9jY0myZ1d785jnqo1LU38FWfLIGNte9q/H8+uDoeA/JcUvsghhfg=
X-Received: by 2002:a6b:105:: with SMTP id 5-v6mr16961739iob.0.1541368751163; Sun, 04 Nov 2018 13:59:11 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Rifaat Shekh-Yusef <>
Date: Sun, 04 Nov 2018 16:59:01 -0500
Message-ID: <>
Cc:,,, IETF-Discussion list <>
Content-Type: multipart/alternative; boundary="000000000000e18fdb0579dde0ec"
Archived-At: <>
Subject: Re: [dmarc-ietf] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 04 Nov 2018 21:59:15 -0000

On Sat, Nov 3, 2018 at 12:00 AM Murray S. Kucherawy <>

> On Thu, Nov 1, 2018 at 2:56 AM Rifaat Shekh-Yusef <>
> wrote:
>> Section 7.1.  Forged Header Fields
>> In addition to a recommended solution, this section has list a potential
>> alternative solutions which the document then states that it is not
>> appropriate
>> for this document to specify which mechanism should be used.
>> Since an implementer is not expected to do anything with this
>> information, it
>> might be more appropriate for this to be moved to an appendix at the end
>> of
>> document.
> Implementers need to be aware of these things in order to make informed
> handling decisions, but we also acknowledge that we can't propose a single
> solution that will work for all operational environments.  That's what this
> text means to convey.
> By my read of RFC3552, that's what this section is for, rather than an
> appendix.
> Section 7.2.  Misleading Results, First paragraph, last sentence
>>    "In particular, this issue is not resolved by forged header field
>> removal
>>    discussed above."
>> which seems to be in conflict with the following statement from section 5:
>>    "For simplicity and maximum security, a border MTA could remove all
>>    instances of this header field on mail crossing into its trust
>>    boundary."
> They're not in conflict.  Even if I remove all instances of this header
> field at ingress and then evaluate DKIM (for example), I have no idea if a
> valid signature from "" should be interpreted such that I
> trust that message more (or less).
> The two paragraphs you're talking about solve different problems.

I thought the DKIM signature is part of this header, but I now understand
that it is a separate header.

>> Section 7.2.  Misleading Results, Second paragraph
>>    "Hence, MUAs and downstream filters must take some care with use of
>>    this header even after possibly malicious headers are scrubbed."
>> How do you expect an MUA or downstream filter to act on "take some care"?
>> Can you elaborate on that?
> If you are a spammer or malware distributor, you can elicit a DKIM "pass"
> by simply creating your own domain and signing your bad email with that
> domain.  The fact that you got a "pass" doesn't tell you anything about
> which domain's signature succeeded, nor does it confirm the message content
> is safe or trustworthy in any way.
> "take some care" means "keep this in mind while deciding how to render a
> message to end users, who might not know to even look at this".
> I guess what I am looking for is a statement about the best case scenario
for an MUA to be able to display a message with some confidence given the
current state of affair.
For example, if there is a valid DKIM, an Authentication-Results header
with dkim pass,and the header was provided by a trusted entity?

> 7.3.  Header Field Position
>> This section explains that headers fields are *not* guaranteed to be in a
>> specific order. The section then states that "there will be *some*
>> indication..."
>> Since the order is not guaranteed, what do you expect an implementer to
>> take
>> away from this?
> "in the general case" and "but most do not".
> So: Most of the time, you can rely on header field ordering to determine
> the sequence of handling.  You are at least certain about whether you can
> trust the tail end of that, because you know your own environment from the
> ingress point.
> Fair enough; I think it is worth adding this sentence to make it clear.

> 7.8.  Intentionally Malformed Header Fields
>> This is a general issue with any header. Is there anything specific to
>> this
>> header that an implementer should pay attention to?
> No, not really, but at the time this text was originally written (see
> RFC5451; this is about the fourth version of this material), it was felt
> this was worth adding.
I guess it does hurt to remind implementer to pay attention to this issue,
but I think it might be useful to state that there is nothing special about
this header to avoid possible question like this in the future.


> -MSK