Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]