----- Original Message -----
From: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>;
"william(at)elan.net"
<william(_at_)elan(_dot_)net>; "Edward Shallow"
<ed(_dot_)shallow(_at_)rogers(_dot_)com>; "Andrew
Newton" <andy(_at_)hxr(_dot_)us>; "IETF MASS WG"
<ietf-mailsig(_at_)imc(_dot_)org>
Sent: Thursday, June 02, 2005 7:46 PM
Subject: Re: Yahoo!'s DomainKeys and Cisco's IIM have merged
Hector Santos wrote:
What I am afraid is how this common spec and its possible exclusive
nature
might define how SMTP behaves to the extent that it is more than just
the
protocol itself by the framework.
I don't understand what you mean by "exclusive". I don't
think that anybody's under the illusion that this is some
sort of silver bullet if that's what you mean.
Exclusivity comes in many forms, namely brand name, popularity or the size
of the proposal vendor. A merged IIM/DK from these big vendors will make a
pronounce statement for for implementation consideration which has factors
which include customer demands.
But this is less of my concern than how it "may mold" the technical aspects
of the SMTP framework in a direction that might be problematic in the
future.
Again, the merger is great news. But does this means that we are now in a
new environment where al incoming transactions are presumed to be IIM/DK
ready?
The reality is that that odds are proportionally much higher it will not be
IIM/DK ready for the malicious and abusive market we are trying to address.
Hence we will continue to be face with dealing with the non-compliant IIM/DK
world which is the majority of the problematic transactions.
I agree 100% with the merging of IIM/DK, the concern from my standpoint
it
show it will fit into the SMTP process and how SMTP vendors will address
the
non-IIM/DK market place. If a system still needs to use other
protocols,
then IIM/DK needs to be compliant with these other methods as well.
I don't think that DK or IIM interfered with the use of other
protocols -- and DKIM won't be any different in that respect.
Sure it does. Its a chicken and egg problem. DKIM is a payload based
protocol. This means that the SMTP process needs to follow decades old mail
flow automation operational practice.
Accept --> delivery or bounce.
By emphasizing payload eception, you deemphasize the SMTP based protocols
that can reject the payload reception thus minimizing bounce attacks.
Today, a simple adminitrator change to dynamic RCPT TO validation is by far,
the biggest backward compatibly deterant to SORBIG based eVirus bounce
attacks.
So the efforts is to reduce the payload reception as best as possible with
little to no false positives.
Of course, I don't know what the DKIMS specs will describe. I have not been
privy to this exclusive group. But it wants to reduce any barrier of
endorsement, then you address this critical issue. Not ignore it.
This will remain the #1 reason why we will be hesitant to drop everything
and begin to support DKIMM. If it has the considering in place, then it
becomes a no-brainer. If it was already considered before the merger, we
would had DK or IIM already in place.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com