That text is not very clear to say the least. It's written in a very
passive voice. What is wrong with the text I provided? It should be made
very explicit like I did with what the responsibility of the sender and
receiver is.
Mike
On 1/25/21 9:40 AM, Seth Blank wrote:
Michael, as an individual, I don't disagree. What's not clear about
the current text?
https://tools.ietf.org/html/rfc7489#section-7.2.1.1
<https://tools.ietf.org/html/rfc7489#section-7.2.1.1>
Email streams carrying DMARC feedback data MUST conform to the DMARC
mechanism, thereby resulting in an aligned "pass" (seeSection 3.1
<https://tools.ietf.org/html/rfc7489#section-3.1>).
This practice minimizes the risk of report consumers processing
fraudulent reports.
On Mon, Jan 25, 2021 at 9:32 AM Michael Thomas <m...@mtcc.com
<mailto:m...@mtcc.com>> wrote:
Why is this controversial? Seriously. What is controversial about
saying that the a report should authenticate? The onus is on the
people who say it does not to lay out the case for why it's not a
problem, not me. #98 has a simple piece of text to remedy this.
it's 2021. You don't use unauthenticated data if you can possibly
help it.
Mike
On 1/25/21 9:25 AM, Seth Blank wrote:
Mike, how do you believe DMARC reports are consumed and utilized?
I think you have a misunderstanding here which is why you're
going down this path and everyone else is pushing back.
On Mon, Jan 25, 2021 at 9:22 AM Michael Thomas <m...@mtcc.com
<mailto:m...@mtcc.com>> wrote:
Taking in information from unauthenticated sources and acting
on it is an operational problem per se. Have we learned
nothing in the last 30 years?
Mike
On 1/25/21 9:19 AM, Seth Blank wrote:
What operational problem are we solving here? Absent
evidence of a problem and strong consensus on the solution,
let's close these tickets and move on.
On Mon, Jan 25, 2021 at 9:10 AM Douglas Foster
<dougfoster.emailstanda...@gmail.com
<mailto:dougfoster.emailstanda...@gmail.com>> wrote:
Since the status quo is unauthenticated, I wonder if
adding a signing requirement will help.
Will recipients discad unsigned messages, or accept
whatever is available to maximize their information
capture? I suspect they will conrinye to accept everything.
I think we would need an identified threat before
recipients would be motivated to discard.
But what about John's problems with receiving reports
that should not have gone to him? I did not understand
the root cause, but I would hope there is something that
can be done. Would signing help receiving sites, those
with less sophistication than he has, be able to sort
out noise more effectively?
On Mon, Jan 25, 2021, 11:51 AM Michael Thomas
<m...@mtcc.com <mailto:m...@mtcc.com>> wrote:
On 1/25/21 8:44 AM, Todd Herr wrote:
On Mon, Jan 25, 2021 at 10:18 AM Michael Thomas
<m...@mtcc.com <mailto:m...@mtcc.com>> wrote:
The main thing I've learned over the years of
dealing with security is to not underestimate
what a motivated attacker can do. Your
imagination is not the same as their
imagination. Closing #98 in particular is
absolutely ridiculous: the report should
already have a DKIM signature or SPF so it's
just a matter of making sure its valid. Why
would you *not* want to insure that? The amount
of justification for *not* having the receiver
authenticate it is a mountain. The amount of
effort to authenticate it is trivial for mail.
Levine's dismissal of security concerns because
he has anecdotal "evidence" from a backwater
domain carries no weight at all.
That's all well and good, but you haven't answered
the question I asked.
What threats do you have in mind? Put another way,
how do you envision an attacker exploiting the lack
of authentication in a DMARC report to his or her gain?
No, sorry, the onus is on the people who don't think
it can be gamed. A bald assertion that it can't be
gamed is very unconvincing. You need to lay out a
miles long case for why it cannot be gamed. And to
what end? #98 has a simple piece of text that should
be added to DMARC to eliminate the possibility of
forgery. You'd need a 10 page threat I-D to explain
why it's not necessary. What is the point of that?
For email, it's trivial to prevent forgeries. Why
would anybody argue against that?
Mike
_______________________________________________
dmarc mailing list
dmarc@ietf.org <mailto:dmarc@ietf.org>
https://www.ietf.org/mailman/listinfo/dmarc
<https://www.ietf.org/mailman/listinfo/dmarc>
_______________________________________________
dmarc mailing list
dmarc@ietf.org <mailto:dmarc@ietf.org>
https://www.ietf.org/mailman/listinfo/dmarc
<https://www.ietf.org/mailman/listinfo/dmarc>
--
*Seth Blank*| VP, Standards and New Technologies
*e:*s...@valimail.com <mailto:s...@valimail.com>
*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.
--
*Seth Blank*| VP, Standards and New Technologies
*e:*s...@valimail.com <mailto:s...@valimail.com>
*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.
--
*Seth Blank*| VP, Standards and New Technologies
*e:*s...@valimail.com <mailto:s...@valimail.com>
*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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
