ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] How to reconcile passive vs active?

2006-08-06 22:37:42
On Monday 07 August 2006 00:20, Mark Delany wrote:
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>

why is is not sufficient to leave things with the simpler -- albeit
more passive -- stance that a sender talks about themselves but
refrains from telling the evaluator what to do with the information?
Yes, that is at odds with a classic model of protocol specification,
but we are juggling among constraints, here.

As one of the chairs pointed out, we are probably circling at this
stage and are consequentially not covering much new ground. (I quote
Dave solely because he encapsulates the differences succinctly).


It obvious that there are two relatively strong viewpoints: one the
passive that Dave describes and one the active that, amongst others, I
describe.

If we take the high ground and accept that both viewpoints are valid
then our job is no longer to argue our differences, rather it's to
work out how we accommodate those differences.

So how do we do that? Do we try and settle on one perspective?  My
guess is that that seems unlikely.

I think we have to try and agree on what we mean.  If we don't and punt it to 
the individual implementers to figure out what the WG meant, then it will be 
confusing both for the implementers and domain owners trying to decide what 
to publish.

Do we try and accommodate both? If so, how?

I think we have to find a happy medium that everyone can at least live with.  
I don't know if we'll succeed, but we ought to at least try.

Or, is this mostly a matter of semantics with the end result being
pretty much the same SSP syntax, but a different set of semantics in
the specification? If so, can we work on the syntax and defer on the
semantics as a means of moving forward?

I think it has some potential to impact the syntax.  

As I mentioned in a note I sent shortly before going on vacation last week, 
some domains will come at DKIM with or without SSP with the view that they 
want to highlight the positive messages that carry their identity and 
increase deliverability for those.  Others domains will come to the protocol 
interested in making it easier/more reliable for others to determine which 
messages pretending to be from them they did not send.

If "I sign everything" means that and nothing more, then that is all the 
complexity that is needed.  If it means "I sign everything and despite the 
fact that stuff will get broken en route to the receiver, I [expect/require] 
the messages that don't validate not be delivered" then it might need to be 
more complex.  While that might work for the second group above, the first 
probably wouldn't want to do that.  So something in the syntax might be 
needed to signal the sender [expectation/requirement].  For those familiar 
with SPF, it would be the difference between ending a record with ?all 
or -all.

If it's agreeable to others, I'd like to suggest that as a way of
moving forward, we focus on the meta-issue of how we resolve this
difference rather than focusing on the details of the difference.

I think there is also a third middle ground view (to which I subscribe) that 
while we shouldn't specify (e.g. the receiver MUST...) receiver policy, we 
should describe how the sender expects/hopes the receiver will deal with 
messages that do/don't verify.

By how we resolve this difference, I assume you have something in mind other 
than spending another week sending 100 e-mails a day to the list?  

I'd suggest that the chairs pick someone with either no strong position on the 
matter or a middle ground position to attempt to draft a consensus statement 
and then let both sides pick on it and see if we get close to a rough 
consensus.

Scott K
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>