[ietf-dkim] punting into near-term standardization

[Dave Crocker <[e-mail]>]

John Levine wrote:
>> I can't gather requirements if I can't make any sense of what you're saying.
> 
> That's a reasonable concern.
> 
> The fog around SSP is so opaque that I'm really wondering if it
> wouldn't make more sense to punt and wait for people to do enough
> experiments to understand what turns out to be useful.


The problem, here, is that it really is not possible to do "experiments" in the
classic sense.  First there is the matter of needing to get adoption among
multiple independent administrations.  Second there is the matter of needing
experience in natural environments.

This combination means that we can field initial, small mechanisms and see how
to enhance them, but we are not likely to get adoption/testing if folks think it
is an experiment.  However the might adopt and test if they see it as an
obviously useful mechanism that will be around for a long time.  However this
requires a compelling value proposition.

So "punting" is probably not the right path.

What is more likely to be the right path is standardizing a mechanism for
publishing SSP statements, and standardizing 1-3 statements that will get
published.

Do we have consensus on 1 statement that senders will want to make and receivers
will want to know?  I suspect we do.

After that we are merely haggling over price.

So let's settle on the 1, 2 or 3 statements with a sufficiently broad and strong
consensus to make it clear that we should standardize them, and be done with it
(for now.)

The two that I vote for are:

1. I sign everything.  If the rfc2822.From field has my domain in it, then I
assert that it will be signed by me.  If you get a message with my domain in the
rfc2822.From field and the message is not signed *by that same domain* then I
assert that the message is not valid.  You might want to consider handling it
accordingly.

2. I send no mail.  If the rfc2822.From field contains my domain in it, then I
assert that its posting was not authorized.  You might want to consider handling
it accordingly.

Both of these will eliminate cases of classic From-field spoofing. (Of course
they will have no effect on bots sending from machines authorized to create
those From fields.)

d/


-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html