Steve Atkins wrote:
On Feb 8, 2008, at 6:13 PM, Michael Thomas wrote:
Wietse Venema wrote:
MH Michael Hammer (5304):
Is DKIM checking sufficient in itself without SSP? How might DKIM-SSP
help receivers (the 3 aforementioned as well as others) leverage their
evaluation of received email whether signed (valid or not) or unsigned?
"known to be good" whitelisting can be done with DKIM-BASE alone.
SSP etc. is about the ABSENCE of valid signatures, and can help to
strengthen the "known to be good" whitelisting process.
You've said this several times, but I don't think that's the range
of all possibilities. Ag.com is a pretty good example of somebody
that I as a receiver don't know but if they're willing to say
"discard this if it's not signed", all other things being equal
why wouldn't I?
Because a noticeable chunk of what you'd be discarding would be
legitimate mail that your users wanted. If an ISP pays more attention
to what senders want than what their paying users want, they don't
deserve to be in the business.
This seems to presuppose that the owner of the author domain doesn't
have any control over their own signing practices. If I publish
discardable, and it's broken or unsigned that's pretty much my
problem if it's legit.
And I'd like to understand where you get a "noticeable" chunk as
we've been running DKIM signing for almost 2 years now and even
with diverse mail use patterns of your average mega-corp we still
get 99%+ verification rates. And we most certainly do not fit the
bill for "discardable". For somebody who really fits the bill
for "discardable", I imagine that the false positives would be down
in the noise of the other reasons you get false positives.
The driving factor for receivers is delivering mail that their users
want, and not delivering mail that their users object to.
Sure. And a domain that tells me that I ought to consider tossing
something that isn't signed is dropping a pretty big hint that your
users are pretty likely to object to it. And if they're wrong, that's
their own problem to correct.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html