ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] user level ssp

2006-09-11 06:59:07
----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>


Why would you want to send a signed message to a mailing
list server that is
a) not DKIM-SSP compliant and
b) known to alter the integrity of the message?

Although it may be practical for a domain to ensure all outbound mail
is appropriately signed, it is _not_ practical for a domain to alter
the operations of thousands of mailing-list services without outright
banning their use.

So I ask again, why would you *blindly* send signed mail to a mailing list
or to just any receiver without having any clue about how they will handle
it?   What do you expect from promusciously sending your precious signed
mail into the wild wild west?  What benefit are you looking for and what you
are expecting?

What good are you expecting from this?

This provides a practical means to deal with signature failures in the
most restrictive fashion possible without expecting the world to
suddenly become DKIM compliant.

Huh? You mean you expect failures when you submit signed mail to a mailing
list?  I don't get it.

All this does is promote the "Cry Wolf" syndrome, harming your
own domain while also putting others at risk of receiving more
DKIM junk disguised as your domain.

The only alternative option when dealing with you or Thomas would
be to not publish any assertion that all email-addresses are
initially signed.

You mean NEUTRAL operations? Legacy Operations?  If I understand you, you're
right.  Legacy Operations is still the #1 requirement.  But once you step
up,  you better cross the tees, dot the eyes, correctly.  Rest assured,
abuse will not be tolerated. Certainly it turned out to be worst than every
before.

Rather than permitting a practical transitional process, perhaps too
many share your mindset and wish to force everything into becoming
instantly DKIM compliant.  That approach is almost certain to backfire
and may cause policy not to be published, or cause DKIM not to be
deployed. : (

You're right.  I expect people with high value domains will avoid DKIM all
together without a dual SIGNER/RECEIVER negotiation concept. They will
quickly realize there is a high risk of exploitation otherwise.

But worst, if anything, the receivers, if they see an increase bombardment
of subjectively determined bad messages with DKIM fingerprints, they might
just use it as a quick and dirty public key detector for filtering the mail.

I already see this now with the junk DomainKeys mail. I can easily see
adding a rule to quick DNS lookup just to check if there is a public key for
mail with DKIM and DKEYS signatures.  No need to bother with the
signature/message hashing verification overhead.

If you want to do this right, when you have to be selective on what you
sign, know who you sending it to and have some clue or expectation about how
its going to be handled. Otherwise, whats the point?  It would be a "Cry
Wolf" waste of time to process DKIM mail without any payoff to it.

In short, half-based solutions don't usually work very well and we have
enough of that already.

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





_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html