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