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.
Not at all. It means that the author domain has some control but not
perfect control over its signing practices, and there will always be
paths that break SSP, e.g., mail-an-article, roaming users sending
through hotel MTAs, mailing lists, forwarders that replace Sender
lines, we all know what they are.
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.
I'm not sure how average a megacorp Cisco is. I'll bet Cisco users
send way less HTML mail that most other businesses, for example. What
do you do about lists like this one that mutate the headers in ways
that break signatures? I gather you may have some kludge to patch it
up, but I don't think you can expect everyone else to do that.
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.
Look back at Steve's previous messages. If the domain's bad advice
makes the ISP drop mail its users want, the users will blame the ISP,
not the SSP record. This would make a reasonable ISP rather gunshy
about believing the advice in random SSP records.
There are certainly heavily phished domains that merit discarding, but
given what a small fraction of the total universe of mail they are,
it's much more likely that most of the domains that publish SSP
discardable will instead be due to admins who don't understand what it
means.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html