Franck Martin wrote:
----- Original Message -----
From: "Scott Kitterman" <[email protected]>
To: [email protected]
Sent: Saturday, April 12, 2014 2:18:33 PM
Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose
On Saturday, April 12, 2014 15:24:48 Franck Martin wrote:
Printed on recycled paper!
On Apr 12, 2014, at 12:25, "Scott Kitterman" <[email protected]>
wrote:
On Saturday, April 12, 2014 18:30:39 Franck Martin wrote:
Printed on recycled paper!
On Apr 12, 2014, at 3:59, "SM" <[email protected]> wrote:
Hi Franck,
At 13:35 10-04-2014, Franck Martin wrote:
Some random thoughts....
[snip]
-IETF recent focus is on pervasive monitoring, increasing security,
prevent identity theft,... DMARC is a tool that helps, it is aligned
with IETF recent goals. It is deployed, widely used, proven
beneficial,
has still some problems, lets' fix them.>
How does DMARC help to in respect to pervasive monitoring, increasing
security, prevent identity theft?
http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/whi
te-> papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf
The recent target problem started with an email, say Krebs...
A bit of research on security and email will give you a better picture
on
why legitimate emails need to be better recognized.
I don't think anyone is disputing that. The problem is that legitimate
emails are being treated as illegitimate.
If you are not disputing that, then you know you need a driving license
because it increase security on the road, and if you don't have one then
you can feel some pain...
We use to keep our doors open, we used to drive without license, we used to
not need TLS, we used to not need anti-spam software,...
Machine learning is not as capable as human learning, algorithms are more
restrictive...
Feel free to propose a better solution.. Quickly..
History in reboot, it all looks like SPF and DKIM IETF wars again....
No. This seems different. Having been involved in these discussions,
writing
and reviewing specs, writing code, and helping educate people about email
authentication since 2004, I don't recall anything like this.
The closes was the discussion about ADSP, but there was a clear understanding
that ADSP was only appropriate for certain types of domains. The same is
true
of DMARC p=reject. It wasn't a problem until Yahoo stepped outside the
generally understood scope of what p=reject was safe for with no notice and
clearly absolutely no care for impact on third parties.
There was also a fair amount of heat around the impact of SPF on transparent
forwarding, but there was never the same kind of "screw you - your problem"
attitude. If you look at the text of the soon to be published RFC 4408bis
there is a ton (too much some people thought) of information about what can
be
done as a sender, mediator, or receiver to mitigate the problem.
I think DMARC is a good idea (that's why I have DMARC records published), but
you have to be careful how you use it.
If they were going to make a change like this, despite the predictable and
predicted negative impacts, it would have been a lot better to give notice so
that administrators could be better prepared. As the confused discussion
around what mailing lists should do now makes quite clear, there is no
consensus on design or operational guidance to mitigate this issue. "mailman
has a new feature" covers about 1% of the problem space.
When I look at the feedback I get on my DMARC reports about 90% of the mail I
send fails DMARC despite good SPF and DKIM deployments due to mailing lists,
bug trackers, web site sharing, etc. For me and many others this is not
about
a trivial piece of the mail stream.
I do agree with you, a bit more time would have helped… but then, I was bullied
(not by you) for wanting to put new features in mailing lists to avoid this
predicted collateral damage… So I did it when I had time on the software I
could… Now people are feeling way more motivated… ;)
This is true with all the other examples you gave, I told people, everywhere I
would find something like this.. The mistake what to not see it would happen
sooner or later.. Security fixes always happen sooner than later...
Sounds like the “you should do TLS - yeah… yeah… whatever…"
anyhow, I think we should stop this thread, this is an IETF list, it is about
working on protocols.
Silly me - I thought we were talking about the DMARC protocol, on the
[email protected] list.
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc