Ok, i'll break it into two separate issues as they are related but not
the same.
Mike
On 1/20/21 3:08 PM, Seth Blank wrote:
Discussion is in scope, per:
https://trac.ietf.org/trac/dmarc/ticket/42
<https://trac.ietf.org/trac/dmarc/ticket/42>
This topic has come up before, and there's always general interest in
pursuing it, and absolutely no one who puts their hand up for either
it being impactful for them or having any interest in implementing it.
i.e. it seems interesting to people, but there seems to be no use case
with operational support to actually add it.
So from those previous discussions, I don't think it's likely that
we'll add reporting beyond mailto:, but it is certainly a conversation
that's in scope when either ticket is opened.
Seth
On Wed, Jan 20, 2021 at 3:02 PM Michael Thomas <[email protected]
<mailto:[email protected]>> wrote:
On 1/20/21 2:59 PM, Seth Blank wrote:
Michael, please open a ticket. I think you're right and some
consideration around this is needed in the document.
What about the https part? If it's not in scope I don't want to
add noise.
Mike
On Wed, Jan 20, 2021 at 2:56 PM Murray S. Kucherawy
<[email protected] <mailto:[email protected]>> wrote:
On Wed, Jan 20, 2021 at 1:21 PM Michael Thomas <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dmarc
<https://www.ietf.org/mailman/listinfo/dmarc>
--
*Seth Blank*| VP, Standards and New Technologies
*e:*[email protected] <mailto:[email protected]>
*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.
_______________________________________________
dmarc mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dmarc
<https://www.ietf.org/mailman/listinfo/dmarc>
_______________________________________________
dmarc mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dmarc
<https://www.ietf.org/mailman/listinfo/dmarc>
--
*Seth Blank*| VP, Standards and New Technologies
*e:*[email protected] <mailto:[email protected]>
*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.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
