On 4/15/2014 12:32 AM, Sabahattin Gucukoglu wrote:
Basically DMARC was always an outsider effort. The effect of a bunch of very important
ESPs (and a bunch of security types) crying "Look! We've solved the email forgery
problem!" was to inspire me to look at the spec, shrug it off as yet another FUSSP
*, and move on. Does this mean that I have materially failed to contribute? Well maybe,
but it means a lot for the spec to be in the IETF where I can point out how broken it is.
:)
I feel the same way.
But after the whole stressful, wasteful dollars, time and energy
situation over 9 years starting with DKIM+SSP, reduced to DKIM+ADSP or
DKIM+POLICY in general, it is not healthy to repeat this with DMARC.
It was clear DMARC couldn't address the key central total mail
integration support requirements if it lacked two things:
- 3rd party policies,
- MLM/MLS support for restrictive policies.
And, to be clear: I respect the goals of the proposal, and will be reasonable
in accommodating it. But to suggest that the contortions of the proponents in
keeping it from the watchful eye of the IETF weren't in some small way intended
to advance DMARC by force in numbers rather than consensus strains credulity,
just a tad.
Yes, that was an obvious problem, marketing hype we tend to ignore,
but it was a concern that they were just repeating the same issues.
Lets remember that DMARC was more about reporting than actually
honoring and literally "rejecting" transactions. Reporting was since
as a potential mail-based DoS attack vector. So my input was to limit
it to TESTING periods and under abuse controls when it was suggested
to DKIM+POLICY reporting.
We saw this again repeated with SPF when in the SPFBIS, the same
people mind you, began to add DOUBT on the whether anyone actually did
reject mail and just simply quarantine the mail. So it became a battle of
SPFFAIL+REJECT vs SPFFAIL+ACCEPT+MARK
When I saw that mentality grow, I raised an SPFBIS issue to make sure
we describe in the spec as two alternative implementation and
deployment option:
- SPFFAIL+REJECT
- SPFFAIL+ACCEPT+MARK+SEPARATE
Without separation, we have a security loophole if the deployment did
not operate by rejecting SPF Failure but instead accepted, marked it
with an Auth-Res header but still delivered the failed message to the
user.
And guess what?
Its happening now again with the new Yahoo/Facebook RRVS proposal.
Again, they are raising the question if whether a reject should be
taken literally or not.
IMO, what has occurred now is a realization that there are actual
systems that are beginning to actually reject the mail based on
restrictive policies. When it happen to a big long time publicly used
domain like yahoo.com, now it became a major problem.
Anyway, it is really too tiresome and stressful to repeat all this.
I thought it was a major mistake and IETF error to make ADSP historic,
done to help make way for DMARC. Who are we kidding? But if thats
the case, once again, the solution is simple:
- Add 3rd party policy support,
- In DMARC deployment guide, provide strong semantics for MiddleWare
to support policies. It can not be ignored.
With the latter, it was a mistake in the DKIM deployment guide to not
raise an Middle Ware resigning implementation note about not honoring
ADSP checking. This issue was raised when the document was written
but largely ignored.
Again, we been through all this. It is all covered with the DKIM
threat analysis and one of the main conclusions is that self-signing
1st party policies are a powerful method to protect against fraud.
ADSP was a proposed standard track work item along with DKIM-base.
DKIM-WG ended on a sour note never resolving this basic issue.
The only reason common agreement and question was whether we can scale
the 3rd party domain authorizations.
So what did we do?
Eventually, Murray saw the issue wouldn't go away. I talked about ASL
(Authorized Signer List) which piggy backed off the ADSP record. It
was meant for the smaller systems. Doug Otis talked about TPA (Third
Party Authorization) but it was too complex. So Murray did ATPS as an
ADSP extension to help with the complexity and scalability questions.
See the wizard at
http://www.winserver.com/public/wcadsp
which allows you to create zone records for ADSP+ATPS+ACL domains. We
implemented this into our software and mail system product, including
the MLS that will deny restrictive ADSP domains.
The work was done. The solutions and conflicts are known. The
question is more a matter of getting people to accept policy more or
as some will like, get rid of it or just don't really honor any kind
of mail rejection -- always accept, mark and hopefully separate.
And lets not forget, the DKIM+TRUST model which is what Crocker and
Levine want to see happen. This market has not materialized
unfortunately, which would be different than the DKIM+POLICY
framework, in that TRUST requires all nodes in the system to query the
same trust databases, otherwise we lack consistency and persistency in
mail distributions. Some nodes will become targets if they lack
subscription to a 3rd party TRUST query system.
--
HLS