Re: [ietf-dkim] A more fundamental SSP axiom

[Michael Thomas <[e-mail]>]

John L wrote:

>>> "I sign all mail" ...
>>
>
>> As I've said before, there are really two different subclasses of 
>> this one.
>> You can have your mail very well under control, but you don't have
>> control over what the damage might be in transit. For some people
>> like banks and phishing targets, that collateral damage is likely to be
>> acceptable. For most everybody else it's not.
>>
>> So I guess it just intrinsically bugs me that the former is a pretty 
>> rarified
>> class  of sender, and is SSP really _only_ for them? (leaving I send
>> no mail aside).  Is there little or no value in knowing that you sign
>> everything, but transit related damage is possible?
>
>
> We have to keep in mind that the recipient is interpreting this stuff, 
> and it's up to the recipient to decide what risk they are willing to 
> accept. Transit damage is always possible, so I don't see any value in 
> pointing that out.  As a receiver, I find a hint that unsigned mail 
> from you is probably bogus to be useful.  Your own opinion of the 
> value of that mail is not.

I think my concern hinges on "probably". For a large domain like cisco 
"possibly"
would probably be closer to the truth meaning that it's certainly a good 
candidate
for higher scrutiny, but if your "probably" is good enough to reject, 
you'd defintely
have a high false positive rate -- from this mailing list if nothing else.

Part of the problem here is the past record of SPF with over-zealous 550 if
there's any hint of bogosity. We, for example, would be forced to take down
a "we sign everything" policy if that were to happen with DKIM -- even 
though
we'll be signing everything pretty soon. If there were a qualifier in 
the "I sign
everything policy" that specifically implies that sending a 550 based on 
a missing
DKIM signature alone is extremely bone-headed" then maybe we can both.
The current SSP has o=! t=y which could in a tortured way be construed to
have that semantic: "I sign everything, but hey I'm testing so take it 
for what
it's worth". If we have something more formalized, them maybe we can
accommodate these two pretty different scenarios.

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