[ietf-dkim] Ignoring SSP failure scenarios is harmful

[Hector Santos]

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