ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: dkim.org (mipassoc.org/dkim) web page updated

2005-11-10 18:18:11

----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Scott Kitterman" <ietf-dkim(_at_)kitterman(_dot_)com>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Thursday, November 10, 2005 6:49 PM
Subject: Re: [ietf-dkim] Re: dkim.org (mipassoc.org/dkim) web page updated


When DKIM signature represents the sending domain, there is no need to
examine other headers for this determination.  Eventually, MUAs should
note the normal signing-domain associated with an email-address listed in
the address book.

What address book?  Where did that come from?

Look, my job as an SMTP vendor is to put a valid email message in a user's
folder, inbin, "database", what have you.  It is expected to be a valid
transaction at the NETWORK CONTROL LINE level.  Whats in the body is the
user's business.  If the network control information is bad, its rejected
period. We are not going pass a broken transaction to the user for him to
decide. We havn't done so in 20 years in all the mail networks we designed
for and we are not going to begin now. Stop trying to define things you have
no control over, and frankly, very little consideration about.

Now if you wish to be evolutionary, then lets talk about new ways to
communicate with the user using new reporting headers, and things of that
nature for situation that are indeterminate in nature.  Thats what we need.
That is what we have been doing at the proprietary level. I can send
information to the our MUAs because we have control over their design. We
don't have control over the public standard MUA designs.  So if we really
want to be product in this area, then we need to talk about new headers for
the MUA to "consider" to support.  We can't force it down their throats and
since that is the case, it should be part of these discussions on how MUA
should behave "eventually."

The majority of abusive email comes from compromised systems.  In fact,
many spammers scale horizontally at trickle rates to avoid detection.
DKIM alone will not offer a reduction in spam.

Yes it can. If you wish to correlate SPAM with "bad" transactions and
network control lines especially new ones that raise the bar. But if you
don't verify it, then its all a moot point.

DKIM is an Equal Opportunity Mail Protection System - BAD and GOOD actors
need to do things right.  If the SPAMMER complies to DKIM, then he passes
the test. Whether the next stage mail analyzer (SIEVE, SPAM-ASSASSIN,
wsSPAMGUARD, SPAMFILTER, WCSAP, etc) passes the message, based on Sysop and
User Defined rules, not DKIM, not SMTP vendor, not IETF, and certainly not
DOUG, thats a entirely different level of concepts that should be outside
the scope of consideration for DKIM.

Why make DKIM so complicated?  It isn't going to BREAK the world and it does
have a very effective way to minimize spoofed transactions.

This approach would log signed assurance/non-assurances (bindings) that
the From, within the same signing-domain is signed by this domain.

More work.

The domain name would be added or removed to/from a name-list in a local
resolver.

More work.

This removes the many DNS lookups per message and replaces this
process with a local lookup that should resolve in microseconds rather
than seconds.  It would also be easy to share this information among
servers/providers.

Wonderful!  Stop trying to invent the "BIG PICTURE" solution. Honestly, you
got it all wrong when it comes to the "Big Picture."  Too many challenges to
many aspects to your design. In fact, just scribbing numbers, you have over
1024 decision points - a massive "SSP" table for your ideas.

When is this charter going to be written by Keith that is acceptable by him?
If he follows anything you are saying, oh well, I guess its on to the next
bright idea to explore.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com



_______________________________________________
ietf-dkim mailing list
http://dkim.org