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

[Hector Santos <[e-mail]>]

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