[ietf-dkim] A more fundamental SSP axiom
mike at mtcc.com
Fri Aug 4 08:04:35 PDT 2006
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
>> 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
would probably be closer to the truth meaning that it's certainly a good
for higher scrutiny, but if your "probably" is good enough to reject,
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
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
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
it's worth". If we have something more formalized, them maybe we can
accommodate these two pretty different scenarios.
More information about the ietf-dkim