[note: FWIW, due to Hurricane Wilma and south Florida commercial power
damages, our company server T1 is down. So I'm using a temporary address
from another source for this list.]
Doug,
I must admit it is hard to follow your thinking.
The way I see it, DKIM is not about interpreting the intent of the sender,
but rather the consistency of the transaction. In other words, how bad of a
liar is the sender and can we detect his lies?
Today, without a doubt, by far, "bad actors" do not attempt to play straight
simply because the current protocols (primarily x821, x822) allow for
"unexpected" verification of the transaction data. This is why by industry
estimates over 60-80% of all transactions are simply "bad."
The SMTP industry has two choices:
- Totally revamp SMTP (i.e. SMTP 3.0), or
- Augment it with new EMAIL security ideas which addresses
the verification (authentication) concept.
Independent of varying opinions, A federal law was passed called CAN-SPAM
which in my view, was a compromise with one major (idealistic) goal - to
allow for commercial direct marketing as long as they didn't lie or
intentionally attempt to "hide" their transactions. Other requirements were
imposed for the right to "spam", but for the most part, the key idea was to
minimize the "liars" and to improve trackability.
So as a SMTP vendor, I really don't care what your mail is about, who is
from, etc, as long as you are who you say you are and if need be, you can be
contacted and/or mail can be returned (bounce). In other words, "play by
the rules" of the transport and email system.
The first thing we added was a CBV (Callback Verifier). The CBV is a
backward compatible SMTP callback to validate the provided return path -
spoofed or zombie, again, the concern was that it is a technically valid
address - not whether you are a good or bad person. Of course, if the valid
was deemed bad, then the transaction was instantly rejected.
Since a CBV is a high overhead consideration, we looked for new ways that
can pre-empt the CBV process to avoid the overhead.
SPF was the direction so it was added. Although I believe SPF is a good
idea, it is not a perfect solution. My concerns were stated from the onset
and the concerns were proven correct. The two concerns were:
- Dearth of mixed domain policy conflict protection, and
- Unrestricted Relaxed Policy Domain Definition and Exposure.
The only reason relaxed policies existed were due to the known potential
forwarding problems where you have IP::DOMAIN relational transition point.
But even before you have this potential problem, you also had inconsistent
transactions which could go unchecked with SPF classic (i.e, HELO domain is
spoofed, but MAIL FROM domain passes the SPF test - mix policy transaction).
The one thing I believed very strongly about SPF or for that matter, any of
the LMAP based proposals where a IP::DOMAIN assertion is made, is that the
best protection is obtained when using LMAP for your own DOMAINS. In other
words, SPF works 100% to protect your local domains. There is no doubt
about this. However, it works less than 100% for remote domains SPF
checking simply because you don't have a verification concept. You can
trust your own domain setup. You don't know about remote domain setup or
trust it.
SUBMITTER and SENDERID were proposed to address the transition point issues.
SUBMITTER is 821 based and SENDERID is 822 (payload) based. SUBMITTER was
viable but as defined conflicted with user privacy issues. With SENDERID, I
still don't see the technical merits of this proposal and I strongly believe
this is one proposal that can create more harm than good.
Which brings me to DKIM.
After it is all said and done at the SMTP protocol and the transactions
passes all minimal checks you made have at the SMTP level, the remaining
consistency check is with the payload.
So to me, DKIM with a strong SSP checking concept, provides another level of
transaction consistency checking that may be used by the SMTP-DATA or
POST-SMTP process to perform a final PAYLOAD check. I don't believe this
checking should include a "REPUTATION" concept at this level. I think "DKIM
signing consistency" is the key goal.
I believe that once this done, widely adopted, it will begin to put a major
dent in combating the "bad liars." You will not address the "good liars"
(spammers who use DKIM), but this begins to change the spammers to move
towards our direction. Even DKIM proves to be a strong deterrent and
spammers will simply ignore it, the GOOD DKIM signers will be protected.
I also believe REPUTATION can also be added later. Although I think
REPUTATION is better suited at the SMTP IP/DOMAIN level, I can also see it
a version of DKIM with REPUTATION added.
But even with REPUTATION, your transaction must be consistent. If its not
consistent, then reputation should not be used as a way to bypass or
override a bad transaction.
In all cases, it is about verification of the transport process entities and
since we lack this with the current SMTP protocol, augmenting it with DKIM
should at the very least be strongly offer a consistency model, not a weak
one.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org