On 19 Aug 2004 at 23:20, Jose Marcio Martins da Cruz wrote: > In what this is something specific to DomainKeys ??? "Bounces are bounces" > and are usually handled as "bounces" not "normal messages". There are many, > many different *AND EASIER* ways to generate false bounces. You don't need > DomainKeys to do that.
Actually, no there aren't so many easy ways to generate bounces where the sender can verify that the bounce *will* occur without testing an e- mail to the site...they just have to look up the DNS of the forged DomainKeys domain. > > that SPF creates...road warriors must send all e-mail through their > > "home server". There are a lot of big ISPs that *never* want to make > > this sort of functionality available. > > This is completely false. You didn't understood DomainKeys protocol. > Read it again. E.g. I live in France, and I just arrived from U.S. - > and I was completely able to send messages using my desktop computer > when I was there, without changing anything, nor at my desktop, nor > at the DNS of our domain. Well, nobody is using DomainKeys to reject right now. But, if you used a [EMAIL PROTECTED] e-mail address in the "From:" (and most MUAs put the same thing in the envelope sender and the "From:"), and you sent without sending through the somehwere.fr outbound mail server to get the DomainKeys signature and somewhere.fr told me to reject messages not signed if they have somewhere.fr in the "From:" header, then I would, and your e-mail wouldn't get through. > See how ? 8-) No, because it didn't work. There is no "DomainKey-Signature:" header in your e-mail to the list, and the roaringpenguin.com server doesn't strip those headers. Your "trick" of renaming your machine won't work either, because I highly doubt that many companies would let employees haul their private keys around, and *no* ISP will let that happen. Even if they did, how many road-warriors have access to an MTA on their machine? Oh, so you want MUAs to be able to do DomainKeys signing...<sarcasm>yeah, that'll help the accuracy.</sarcasm> BTW, another flaw I have found is that "selectors" can't work because I attempted to look up the _domainkey.ensmp.fr to see if I should have rejected your e-mail. A "valid" ensmp.fr e-mail would have had a "DomainKey-Signature:" header to tell me what selector to use. But, since there is none, the default must be used. So, that means you need a bogus (but legal) record in the base domain. Having that around is one place that the public/private key could be cracked without a domain noticing as quickly if they use "real" selectors for everything. A solution to this is to add something to the DNS spec for the "o=" to show that nothing can *ever* be signed in such a way that a lookup gets here. Since I'm back on the long rant, how about this funny statement from the defining text: "Recipient systems should only retrieve this policy TXT record to determine policy when an email fails to verify. Recipient systems should not retrieve this TXT record for email that successfully verifies." And how, exactly, would I verify the signature without grabbing the public key, which is stored in the exact same TXT record? I could guess at the public key, but that might take a while. > No. The mail list server signs again the message. This is one way to > do that. There may be others. Only if they participate. Still, changing the "From:" header makes mailing lists somewhat useless, since it's a pain in the butt to get most MUAs to show something other than the "From:" without turning on all headers. Also, every single MUA can sort on the "From:", but only a very few can sort on "X-Originally-From:". > This isn't in any way some sort of forgering From header, as, if you > subscribed to the list, you have some trust on it. *I* may trust it, but my ISP sure doesn't know about it. Then, too, there is David's comment about most MUAs only showing the "comment" part of the "From:" header, not the e-mail address, thus rendering any checks of the e-mail address contained therein mostly useless. > Why do you talk all the time "reject"/"accept" ??? These aren't the > only possible actions ! If the TXT record says "we always sign our messages" and I get an unsigned one (or, better yet, a signature check failure), what do you suggest I do? Add scoring weight to a SpamAssassin rule? Gee, since my current setup catches 99% of SPAM (and many of these are forgeries of the kind that DomainKeys is supposed to "help me spot") with no false positives, what use is DomainKeys? Also, if I get to the point where I have decided I can't trust the message, do I really want a user to have *any* chance of seeing it? Go ask Citibank, or Chase, or Bank of America, or eBay and see what answer you get. If a receiving site doesn't reject on DomainKeys signature verification failures, then DomainKeys helps improve trust by so little that it is useless. Likewise, if there is a reason the designers of DomainKeys think I shouldn't let a e-mail with a verified DomainKeys signature through, then even *they* don't believe in its effectiveness, so why should I? > The server will sign it only if it was sent from trusted machines. > If a spammer can be able to get a signed spam from some other domain, > this meant that it succeeded to penetrate on that domain. So the > problem isn't DomainKey but the security of that domain. No, any domain that signs outgoing mail with DomainKeys *and* gives away free e-mail addresses allows you to get a signed e-mail from that domain, and it can contain anything you want. -- Jeff Rife | SPAM bait: | http://www.nabs.net/Cartoons/Dilbert/TechSupport.gif [EMAIL PROTECTED] | [EMAIL PROTECTED] | _______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
