Re: [dmarc-ietf] Authentication of reports

Seth Blank <> Wed, 20 January 2021 23:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 742793A15B1 for <>; Wed, 20 Jan 2021 15:00:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9I2CveJwLJlp for <>; Wed, 20 Jan 2021 15:00:03 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D5D43A15B0 for <>; Wed, 20 Jan 2021 15:00:02 -0800 (PST)
Received: by with SMTP id n18so31635vsa.12 for <>; Wed, 20 Jan 2021 15:00:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jwxJZoK2Jlzi3ytfQONIq1XCD4jVtkIkDMjORE9Avs8=; b=fJC4Q8+D+4NNqlLTRy9mwvkwiopEKXYUhybx5qq4OeEE7AMPCXiCZqxa0UNdxI7z7r SxcPvIBo+Lo9kDLisp+ooC7BkR6soPk9lqHNnrigV9ocoAbkUWa7Rlq9d0NsSYRU5oei eIls2iJeZZ8/3Cg9VUEEr99a5xKzH/Htz+mZjYVTDxm1NunaktW9gu+PIAk/OSeoRPqg gJT7UEuUXFB+hE0fb/YIAlsJisbwQVUiDtY+SYme9M9U6oZWZrqlYVOmfpa1WQxukug8 5S3EkPUA+sqnyYXFh0IkwAQkEo7bv3oVoVDYpLTa6eMmHwRrgad6a2Q15fXKGcq3M0pe OBtQ==
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; bh=jwxJZoK2Jlzi3ytfQONIq1XCD4jVtkIkDMjORE9Avs8=; b=jN4Q88nfUGLFWWiXX6A43oQp4eeTWW894YP1QRkfbByuF6zkWMXbHK56dC/M+WvRZa uS1aR/cXm83aixc7Av68Y83AkZhxIy1K4eiosvVuVC8n7WC41cWjIyMzQrWFwpn6QPZg 9V9MqbjJkesMacR5D/w2QxcdmC6VLUJGd1iIKtvj1j6RIlzcq5PICLsZD3jqr7KlBQfA 8PoOrcaOKElu6E9NwRvDqIMsC2qpUtsfD9uNe1/nDL5hns2Sed0Djj3p6mizSN5T5V8i nQ2RJQ4jfYzd0ukJ2Go9A1l3Nt3mtcrhKlFOnIa75vSUo3xojED0p4TNAu3iCGL0jyE8 eptQ==
X-Gm-Message-State: AOAM5335n63qh8Bk7po+T2y7523iaepN3yK7XiT6Mi0KptwEZe7KZyVO N4XUyc1XyRWLlQDbFUDRG1hvgGHFlj5OmZOIlVtwnPSepQo=
X-Google-Smtp-Source: ABdhPJzZMXkRq5tlJts0hM7dMWpibJjWo60u6pnWvnYdm/HO/kHJd5V50UMKyYAkA3pXqsnAQdtMzN4LbjLYd5ucybU=
X-Received: by 2002:a67:efd9:: with SMTP id s25mr8187952vsp.56.1611183601538; Wed, 20 Jan 2021 15:00:01 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Seth Blank <>
Date: Wed, 20 Jan 2021 14:59:50 -0800
Message-ID: <>
To: "" <>
Content-Type: multipart/alternative; boundary="0000000000003ce6f405b95ceaa2"
Archived-At: <>
Subject: Re: [dmarc-ietf] Authentication of reports
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: Wed, 20 Jan 2021 23:00:06 -0000

Michael, please open a ticket. I think you're right and some consideration
around this is needed in the document.

On Wed, Jan 20, 2021 at 2:56 PM Murray S. Kucherawy <>

> On Wed, Jan 20, 2021 at 1:21 PM Michael Thomas <> wrote:
>> I just scanned through DMARC and I couldn't find any security
>> requirements/mechanisms for the failure reports. I would think at the
>> very least the receiver consuming the reports ought make certain that
>> the report at the very least have either a valid DKIM signature or a SPF
>> pass. Unauthenticated data is always the source of mischief, and I'm
>> sure that there have to be attacks that are possible with
>> unauthenticated reports. At the very least this should be a security
>> consideration, and most likely should have some normative language to
>> back it up.
> I thought the usual rules about when you should or shouldn't trust a
> message ought to be applied, but I guess we never actually said that in the
> document.  We certainly could.
> Since I'm sort of new, it's been unclear to me whether whether having a
>> new https transport mechanism is in scope or not -- it seems to come up
>> pretty often -- but I'm not sure how people would propose to
>> authenticate the report sending client. That seems to me to be a basic
>> security requirement for any new delivery method. The problem here is
>> there isn't a client certificate to determine where the report is coming
>> from or any other identifying mechanism. An alternative might be to DKIM
>> sign the report itself, but the long and short is that it would need to
>> be addressed.
> As I recall DMARC originally (in its pre-RFC versions) did have "https" as
> a supported scheme for "rua", but since nobody implemented it during the
> years DMARC was in development, it got dropped before publication.
> -MSK
> _______________________________________________
> dmarc mailing list


*Seth Blank* | VP, Standards and New Technologies
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.