John Levine wrote:
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.
This is making an erroneous presumption that this may not be desirable
by any segment of the domain market place.
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.
The #1 problem here is that we designing a protocol based on your, mime
and anyone's guesstimates of numbers. The protocol is flawed right out
of the box.
> What do you do about lists like this one that mutate the headers
> in ways that break signatures?
They are not candidates for strong policies and getting any real benefit
and the DOMAIN will know that. If it wishes to continue to allow its
domain to be used in open and unknown highly exploitable manners, it
can't expect it be safe from abuse. That was established long ago.
> I gather you may have some kludge to patch it
> up, but I don't think you can expect everyone else to do that.
Exactly, which just reaffirms the fact anyone who is going to operate in
this relaxed exploitable manner SHOULD not expect any much benefit from
any of this.
But you wish to deny domains, and in my view a vast number of domains,
the opportunity to get a high degree of benefit from DKIM+STRONG policy
modes of operation. This ASP model lowers the incentive to support DKIM
where inherent default policy of domain abuse ignorance is the mantra.
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.
So? This sort of stuff commonly happens today in other ways! In fact,
it is perfectly valid feedback in the support process to rectify the
situation in whatever it takes to do so.
Certainly, the DMA market has a right to do business with users in a
vendor-user relationship. CAN-SPAM established this valid relationship.
But, if the DMA market expects to raise the bar of standard SMTP
transactions by marking its SPAM with DKIM signatures and expects these
*highlighted* messages to help get their foot into the door, then they
should also realized by making its mail "special" it also comes with
special scrutiny as well. Can't have it both ways. The DAC VBR-INFO
advice is only going to help tell us, "So far So good."
However, if the DMA market wishes to really help themselves and tell
receivers that their new form of SPAM are have DKIM signatures, they can
help keep their reputation harm lower by exposing the idea received
unsigned messages purported from them are no good and should be
rejected, then we are all winners:
"Sure, I send SPAM, but my own SPAM, not SPAM from others"
> This would make a reasonable ISP rather gunshy about believing
> the advice in random SSP records.
It seems you are in denial of the quickly involving fact that DKIM is
becoming dubious with this ASP model.
I can imagine HIGH_VALUE_DOMAIN.COM, a paying member of DAC is being
told by DAC to sign all its mail with DKIM and more importantly add the
VBR-INFO header too.
But bad guys see this and say:
"Hmmmmm, I better stay away from DKIM or any VBR-INFO and see
what happens."
So now receivers get HIGH_VALUE_DOMAIN.COM messages with no DKIM
signature, no policy information that one is required and no one to ask
about it.
Who is harmed?
- Receivers with abused of their system,
- Domains with increased reputation harm of sending bad mail,
- End users who may be phishing victims,
What's your answer to this?
The only reasonable answer I see is SSP-02/ASP DKIM=DISCARDABLE or a
SSP-01 DKIM=STRICT|ALL set of policies that will provide a BIG hint to
the receiver unsigned message where it is expected is obviously fraud.
But you want to deny this to any domain because you feel domains are
still going to allow ROAMING usage of their domain from any site or service.
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.
The last time a protocol stated such insightful "small numbers" case:
RFC 2821:
7. Security Considerations
7.1 Mail Security and Spoofing
...
This specification does not further address the authentication issues
associated with SMTP other than to advocate that useful functionality
not be disabled in the hope of providing some small margin of
protection against an ignorant user who is trying to fake mail.
Got it so wrong to the tune of a 10's of billions dollars world wide
industry problem. Its no longer a small margin of ignorant users but a
world wide industry problem.
I hope we can keep flawed subjective policies like the above and being
repeated here, out of the DKIM POLICY protocol design process.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html