[Mimedefang] sendmail spf milter plugin for sendmail 8.13.0

[Jeff Rife]

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 me at somehwere.fr 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 
AskDOJ at usdoj.gov |  
spam at ftc.gov     |