On Sun, 2006-09-10 at 20:58 -0400, Hector Santos wrote: > ----- Original Message ----- > From: "Douglas Otis" <[EMAIL PROTECTED]>
> >> 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? An administrator may make an assertion all email-addresses within the domain are initially signed, AND only compliant services are used. Making the first assertion, the administrator needs to ensure users utilize specific outbound services. This added requirement should not limit where messages are eventually sent. Making the second assertion will impact an ability to participate in a mailing-list. This second assertion might be desired to curb spoofing by limiting acceptance of invalid signatures as an alternative to reliance upon retained email-address annotations. Retained email-address annotation also prevents look-alike attacks however, and provides far better protection. This second assertion might be seen as just a stop-gap measure. Indivdual users may decide to participate in a mailing-list where a signature is likely damaged. The eventual recipients are the mailing-list subscribers, and the situation where signatures are damaged will not change anytime soon. When the first assertion is made, email-addresses with invalid signatures could be limited to sources known to damage signatures, if limited at all. You are suggesting that by signing a message, it should only be accepted when the signature verifies. This will greatly discourage deployment of DKIM, let alone publishing policy that all messages are initially signed. Consider that DKIM annotations based upon retained email-addresses offers superior anti-spoofing protection without a need to block messages with invalid signatures or to selective sign messages. > > 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. Absolutely. How do you expect initial signatures to survive the typical formating and flattening, in addition to subject line changes and unsubscribe and ad information normally appended or prefixed to the message body? Any effort to accommodate message modifications only invites abuse that could now come from anywhere, rather than known services. > >> 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. A bad actor can sign using DKIM and publish any highly restrictive policy they wish. Navigating policy aimed at blocking messages will prove most difficult for legitimate users and administrators. The bad actor will keep turning the knob until their messages are accepted. > > 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. Exactly how would DKIM be exploited? An invalid signature should offer no advantage. > 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. While this approach might be employed in an attempt to curb replay abuse, this will also need to accommodate the number of subscribers in various mailing-lists. List that identify mail-lists should be easy to compose. Perhaps bulk senders might be forced into using unqiue signatures for each subscriber. : ( > 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. This would leave your domain exposed to abuse once that strategy becomes apparent to the bad actors. > 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. While that strategy might be considered plausible, it seems unlikely to find concensus. SMTP is a store and forward system. There is no way to know where the finial destination of the message might be, and what might happen to the message in transit. DKIM should be robust and able to deal with damaged signatures. The use of retained email-address annotation ensures protection is not lost as a result of signature damage. > In short, half-based solutions don't usually work very well and we > have enough of that already. There should be a strategy that makes sense and that is easy to administer. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
