[Mimedefang] sendmail spf milter plugin for sendmail 8.13.0

[Jose Marcio Martins da Cruz]

Hello,

Ok, I'll try to "long counter rant" some of these messages... and 
explain some points, with copy to dk-filter mailing list. Maybe 
not all points, it could be too long.

First of all, before "counter ranting", let me explain a point which will
never be solved, nor by DomainKeys, nor by SPF/MARID/Caller_ID.

The only thing DomainKeys is to tell : "OK ! This is a message sent by
my domain". So, spammers may, them too, use DomainKeys to sign their
spams. It's quite easy, for a spammer to create a "use once domain",
create all DNS records to auth it (SPF or DK). There is no technical
solution for this, unless registrars stop accepting to register domains
without really identifying the people who requested it.

Say, some anonymous guy registers the domain "porn dot com", sets up
SPF/DomainKeys/Caller_ID records... you can do not against that, other
than doing, e.g. content checking, as you already do nowadays.

On Tue, 17 Aug 2004, Jeff Rife wrote:

>>/ http://www.sendmail.net/dk-milter/
/>>/ "
/>>/ As part of our broad-reaching effort to spur the testing and eventual
/>>/ broad adoption of sender-based email authentication to address fraud and
/>>/ spam in email, Sendmail, Inc. is releasing an open source implementation
/>>/ of the DomainKeys by Yahoo! specification for testing on the Internet.
/>>/ "
/
> Oh, yuck.  Sorry for the long rant, but...
>
> Basically, the description memo says it takes the actual domain in the 
> "From:" header, looks up a public key from the DNS server for that 
> domain, and then uses that public key along with the signature in the 
> "DomainKey-Signature:" header to see if the message is OK.  Anybody see 
> the problem with this?

No !

> If the receiving server doesn't reject, but instead bounces, the bounce 
> goes to the *envelope sender* (per the RFC).  Thus, if a bad guy 
> doesn't like a domain, they just have to put a bogus envelope sender 
> from that domain, a bad "DomainKey-Signature:" header/"From:" header 
> combo, and then send the e-mail to someplace that checks DomainKeys but 
> bounces instead of rejecting.

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.

> 
> Second, if a server gets an e-mail with a "From:" address of 
> "somebody at example.tld <http://lists.roaringpenguin.com/mailman/listinfo/mimedefang>" and example.tld says (in DNS) "our e-mail must 
> be signed", do you reject?  The problem this creates is the same one 

No ! It just says : here are the public key to verify our signed messages.
It's up to you to decide what you will do with that information.

> 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.

See how ?  8-)

> Next, let's talk about mailing lists.  All messages in this list seem 
> to have a "From:" header that isn't a roaringpenguin.com address.  Now, 
> if there were already a "DomainKey-Signature:" header, the rp.com 
> server shouldn't add one or modify the existing one because they can't 
> sign for "example.tld".  But, the nice footer at the bottom of the e-
> mail can't be added, since that would screw up the signature.  And, so 
> would "Received:" headers (or *any* tampering with the headers) since 
> "the default signature is an RSA signed SHA1 digest of the email 
> headers and content".  This *requires* that my signing MTA talk 
> directly to the final endpoint "checking" MTA.

No. The mail list server signs again the message. This is one way to
do that. There may be others.

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.

> Their description of the workaround for "Received:" headers basically 
> means that you either trust that somebody else did the check correctly 
> or that you must jump through some hoops to do the check yourself.  
> There's also the issue of making it impossible for a mail server to 
> translate 7-bit to 8-bit or vice versa.

There is no need for an intermediate mail server to do this kind of
message manipulation.

> 
> Their "solution" (that won't work at all) for e-mail lists: "A final 
> possibility is that MLMs may not need to participate in DomainKeys as 
> recipients have other means of sufficiently recognizing legitimate MLM 
> traffic, such as List-ID: headers".  Well, gee, even if they don't 
> "participate", if the e-mail comes from a "participant", and ends up at 
> a "participant", end users may never get a say in whether to reject the 
> e-mail or not.

Why do you talk all the time "reject"/"accept" ??? These aren't the
only possible actions !  And these others explains what path the
message will follow - a sort of weighted path, depending on
verification results.

> Last (and this is really the one I hate), they also have hooks for a CA 
> system that means you would now have to pay money each year to have 
> your e-mail "certified".  Sure, it wouldn't start out that way, but 
> *some* large site would start refusing e-mail unless the public key had 
> a CA-cert chain to somebody *they* trust.

Certificates will be an option, not the only one. There may be different
levels of accreditation. In the same way, if you go to the bank and ask
to get $50 from your account, they will ask you for a single ID card and
do little checks. If you ask for $50000, they will surely do much more
checks.

Did you though about license issues ??? 

*David F. Skoll*  <http://lists.roaringpenguin.com/mailman/listinfo/mimedefang>dfs at roaringpenguin.com <mailto:mimedefang%40lists.roaringpenguin.com?Subject=%5BMimedefang%5D%20sendmail%20spf%20milter%20plugin%20for%20sendmail%208.13.0&In-Reply-To=41229079.32066.2945D9C9%40localhost> wrote on 08/18/2004 08:39:53 AM:

>/ Furthermore, DomainKeys is trivially defeated with a replay attack.
/>/ Send yourself the spam through the signing server.  Now you have a 
/signed
>/ spam that you can re-mail far and wide.  Of course, you can't mutate it,
/
Also false. 

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.

And, guys... There are easier ways to get a signed spam, than penetrating
on some other domain.

>/ which might increase the effectiveness of DCC and the like, but it still
/>/ means you can't *really* trust a properly-signed message.
/
Best,

Jose Marcio

-- 
  ---------------------------------------------------------------
  Jose Marcio MARTINS DA CRUZ           Tel. :(33) 01.40.51.93.41
  Ecole des Mines de Paris              http://j-chkmail.ensmp.fr
  60, bd Saint Michel                http://www.ensmp.fr/~martins
  75272 - PARIS CEDEX 06      mailto:Jose-Marcio.Martins at ensmp.fr