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

[Hector Santos <[e-mail]>]

On 4/19/2014 1:08 PM, [e-mail] wrote:
>
>> I agree, but I also think there is another element of the
>> situation that got us here, and that has led us close to other
>> problems in the past.  When the RFC Editor is asked to publish a
>> non-WG document (i.e., either an individual submission through
>> the IETF stream or as an independent submission) that could be
>> construed as some sort of standard (whether actually standards
>> track or not) or approval of an IANA parameter registration is
>> on the basis of expert review, there as a potential for the
>> appearance of conflicts of interest.   Those conflicts need not
>> be of the traditional legal or financial variety.  They can
>> occur (or be perceived to occur) when someone's institutional or
>> organizational relationships outside the IETF might lead people
>> to suspect that review and decision-making might not be as
>> careful, unbiased, or primarily reflective of the interest of
>> the IETF or the broader Internet community as we would like it
>> to assume it always is.  For situations where troublesome
>> relationships exist or might be inferred (even by those
>> suffering from mild paranoid), we need to get much more careful
>> about disclosure of the relationships involved.
>
> Good point, and I agree.
>
> These waters are going to be difficult to nagivate, but I don't see any
> alternative.
>

Maybe I should of followed with my gut instinct and followed through 
with my appeal a few years back when this whole situation we have 
today was the crux of the main philosophical debates of TRUST vs 
POLICY DKIM framework and a deemphasis of policy and lost of a 
standard track WG ADSP policy proposal was going down the drain with 
conflictive trust interest dominating the direction of DKIM.

But with seeing the WG chairs and ADs interest also being in conflict 
as well, including one AD recusing himself from my initial appeal 
interest AD/chairs contact, I knew it was time to give up. In a chat 
with Eric, who lead the early DKIM policy framework work, when 
Levine's poison pill ADSP hijacked the policy work, he said it was 
over as far as an IETF standard work item. It will have to be 
revisited from outside the IETF with some trade group.  DMARC is a result.

In that vain, I am partially the blame for backing off. How much 
talking can you do? At this point, now I am being excommunicated. It 
wasn't fun.  Its not like the chairs and the Ads were not aware of the 
concerns. But I guess I didn't have enough influence. I didn't attend 
meetings. I didn't have get to know the folks or them me.

But I knew this was going to be a major problem when the IETF was now 
abandoning ADSP for the same reasons you are seeing now with DMARC. 
Essentially both lacked 3rd party semantics.  So its somewhat surreal 
that DMARC would be now marketed by the IETF when the same ADSP 
problem did not get addressed. It can't be made any more simpler than 
that.

Overall, the technical issues were obvious. But there was two basic 
attitudes that was hard to overcome and I think still needs to be 
overcome:

   1) A mindset that REJECTION is bad.  Accept all mail and let users 
decide was
      the prevailing mindset.  It was a SYSTEM wide vs USER filtering 
design
      issue. As a developer, it means BOTH options would be available 
for the
      operators to work with.   But overall, the ideas of 
deterministic system
      wide rejection was too little too much for many of the IETF mail 
vets.

   2) The 3rd party Trust/Reputation Market potential was too great to 
allow
      self-signing policy based system marginalized this trust market 
potential.
      New ventures had started by the leads of the DKIM project. 
Again, brought
      up but what were you going to do.  For me, lead the way, trust 
and policy
      do co-exist and we would be better for it, if others vendors 
refused to
      see that. But no, POLICY had to go!  there was no compromising 
whatsoever.

Anyway, I'm somewhat tired of it.  Much development time was put into 
DKIM, ADSP, ATPS over the 9+.  If the attitudes don't change now that 
DMARC is here, well, I don't see any hope with this issue unless fresh 
new synergism and policy support advocates folks get involved. We got 
the usual typical relatively few people that appear to be considered 
the main leads with these IETF mail related projects and that has to 
improve or in this case, finally change a few key folks position on 
DKIM + POLICY and help lead the way with 3rd party policy support that 
is workable, acceptable for all.

If DMARC is the going to be the "method," the "language" then it can 
be fine tuned with IETF based extensions that the silly DMARC.ORG 
folks, whoever they are, can not stop from happening in the same way 
we somewhat tried to keep ADSP alive with the ATPS extension.

If thats a problem, then how about this>

      I proposed ADSP to be remove from Historic status, and 
reestablished
      as a Proposed Standard.

Why does this make sense?  Well, there are systems that support ADSP, 
there is APIs, there is running code, and its still too early with 
DMARC to completely eliminate ADSP.  Since its not perfect, a 
competing ADSP may actually get the DMARC.ORG to be more agreeable 
with IETF related concerns.

-- 
HLS