Re: [ietf-dkim] Re: sender practices, as opposed to something else

Frank Ellermann wrote:

> > DKIM-BASE does solve the forwarding problem
> DKIM doesn't "solve" a "forwarding problem", for starters it
> doesn't have any "forwarding problem", no need to "solve" it.
I know one thing Frank, there is no way on this living earth am I going 
to get into a semantics game with you. But ........
If I send mail to a host which is listed as the MX destination, and 
unbeknown to me this SPF ignorant host receives and relays to mail to 
some "real final destination" host using SPF, the real host will result 
with a SPF=FAIL.
If I was DKIM signing my mail, the "real final destination" host 
supporting DKIM, won't reject this multiple hop relay issue that raw SPF 
has.
> Comparing http://www.openspf.org/Statistics with a not yet ready
> draft would be pointless, and SSP is targeted for a far narrower
> audience, victims of phishing.  
SSP is not targeted at phishing targets nor can address it.  Its a 
chicken and egg situation.
> > If there is one legitimate comparison, then we should look at
> > the relevance of DomainKeys (DKEYS).
> Comparing the deployment a not yet ready draft with a historic
> RFC, what's that good for ?  
I know you like to  compare the RFC documents.  :-) I will compare the 
implementations where they are *almost nearly* the conceptual same when 
SSP is not considered.  After all, if not all, most people who 
supporting DKEYS and DKIM are using the same code.  Take away SSP and we 
have the same low benefits with DKIM that DKEYS has.
> > DKIM risk falling into the same waste land if we don't resolve
> > the SSP issue.
> I don't get it, how can DKIM fall into waste land when GMail,
> Ironport, and others use it?  
Because by far the majority of the receivers are not processing it.
There is little payoff in processing it without a policy concept.

For example, I just send this from my gmail account to my isdg.net 
account, and the message had this gmail DKIM-Signature, and the 
Domainkey-Signature header (I broke it up for readability should only 
the relevant parts)
DKIM-Signature:
  v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=gmail.com; s=gamma;
  h=domainkey-signature:
    received:
    received:
    message-id:
    date:
    from:
    to:
    subject:
    mime-version:
    content-type:
    content-transfer-encoding:
    content-disposition;

DomainKey-Signature:
  a=rsa-sha1; c=nofws;
  d=gmail.com; s=gamma;
  h=message-id:
    date:
    from:
    to:
    subject:
    mime-version:
    content-type:
    content-transfer-encoding:
    content-disposition;

There is no SSP record for gmail.com.  The only reliance I have that 
this is even worthy of complex processing is when its valid 1st party 
domain.  Which has no value in the trust field unless I just want to say 
that "Ok, it came from GMAIL, there was no mail integrity changes."
Here the problem:

  1) 3rd party signer, but uses From: xxxx(_at_)gmail(_dot_)com

     If this is spam, I have a lot of wasted processing time,
     never mind the potential harm to end users.  They can
     also continue to spoof my gmail.com against me and others.

  2) No Signature,  someone can continue to use my gmail.com
     and send spam, malicious mail.

  3) DKIM exploits can use a fake signature or the same
     signature for all its bulk spamming.  The idea is to
     make it "look ok" even if its not valid.
     Wasted processing.

By having an SSP record, GMAIL.COM will be able to have some level of 
control. It helps protect my server, my users, other users and the 
GMAIL.COM brand name is better protected.
Now GMAIL.COM is an ESP and like other free accounts large ESPs, the 
gmail.com domain is already considered a junk address, people use it for 
JUNK, just look at your JUNK address.
         hmdmhdfmhdjmzdtjmzdtzktdkztdjz(_at_)gmail(_dot_)com

If you don't think people see that with a "hmmmmm" pause, you should 
because it appears to be just like all the other spam junk. But thats 
besides the point.
GMAIL.COM has just increased the potential harm on others by exposing a 
no SSP DKIM operation.  There is little benefit without some policy concept.
Now, change that to BANK.COM where it is a much more guarded domain of 
high value, the issue is even more problematic. In other words, 
gmail.com is a big company but its domain is not a "High Value" domain 
because it can be used for anything.  Most people I know use the 
gmail.com account to direct their junk to and also use it for junk sign 
ups or to hide their identity, etc.
With Bank.com, would be a high-value concept because its limited in its 
usage - at least the bank would prefer it that way.
If bank.com does not have a strict SSP policy, it will be just as 
vulnerable as gmail.com.
A strict BANK.COM policy would prevent ALL 3rd party abuse, spoofs with 
no signature and also mail integrity problems it does not expect.
> Unfortunately GMail doesn't
> publish SPF FAIL, but they offer at least a PASS, apparently
> they also reject FAIL.  No waste land in sight, or did you
> mean PRA ?
I meant SSP.

Frank, just as a side note, you can not assume that all parties will be 
used every technology in place. DKIM/SSP must have a benefit on its own. 
 Of course, smarter systems will offer SPF/PRA or other things as well, 
but you can't design the DKIM/SSP protocols on the assumption they will 
be using other stuff as well.
> Domainkeys also didn't fall into waste land, it was published
> as historic after DKIM was ready, intentionally.
Well, again, I wasn't referring to "RFC" stuff.  I was referring to the 
thousands of message we received with Domainkey-Signatures and its 
ignored.  However, I am interested in processing DKIM if it comes with a 
SSP concept.
> > I am not looking to lock in DKIM implementation with some
> > very limited "batteries required" Trust Service concept.
> If you use DKIM as receiver without some kind of white list
> I've no idea what you are actually doing, but IMO you don't
> need a Trust Service to create a white list, roll your own.
I did say local or 3rd party.

For us, in this particular area, we use an automated white/black list 
system.  Automated white when users send mail out to people, automated 
black when outbound mail deliver attempts is exhausted. I don't wish to 
get into the actual details so please don't nit pick on that. :-)
> You could even check some kind of "best guess SSP" before
> SSP is ready, like "best guess SPF" that's nothing that will
> end up in a RFC, it's deep in "receiver policy" territory.
My mentality in all this is solid, automated first level deterministic 
methods.  Leave the subject guess work to other artificial intelligence 
and/or heuristic concept at the second layer.
--
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