[Mimedefang] sendmail spf milter plugin for sendmail 8.13.0

Matthew.van.Eerde at hbinc.com Matthew.van.Eerde at hbinc.com
Wed Aug 18 15:05:10 EDT 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff Rife wrote:
> 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.

This is a fundamental problem with bouncing vs. rejecting, and has nothing
to do with Domain Keys.  Hopefully all sites hip enough to use DomainKeys
will reject rather than bounce when a bad DomainKey signature is encountered.

> Second, if a server gets an e-mail with a "From:" address of
> "somebody at example.tld" and example.tld says (in DNS) "our e-mail must
> be signed", do you reject?  The problem this creates is the same one
> 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.

Yes, reject, of course.  Big ISPs that don't want this functionality just
don't have to implement DomainKeys.  I have a feeling that people who get
sick of their email getting lost in "junk" folders will move to more
anti-spam-conscious ISPs.
 
> 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.

To the "checking" MTA, sure - not necessarily the final endpoint.  If you
have a pass-through MTA running MimeDefang in front of your Exchange server,
just make sure to do the checking on the MimeDefang server.  Once your
DomainKey checking is complete, you can add/change/delete any headers you
like.  Maybe add a X-DomainKey-Result: Pass, for example.

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

Translate at will - after you do the check.

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

Or just check on the Sender: header rather than the From:...

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

Could be.  Price of the commercialization of the internet.

And David Skoll wrote:
> 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,
> which might increase the effectiveness of DCC and the like, but it still
> means you can't *really* trust a properly-signed message.

Ehhh... DomainKeys can be trivially saved from this trivial defeat.
Just have the sending MTA create separate envelopes for each recipient.
Then add an X-Envelope-To: header.  Finally have the MTA sign each envelope
independently before delivery.  The X-Envelope-To: header will be part of
the digest.
On the receiving side, any RCPT TO: <> X-Envelope-To: invalidates the
DomainKey check.

Matthew.van.Eerde at hbinc.com                      805.964.4554 x902
Hispanic Business Inc./HireDiversity.com         Software Engineer
perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg,"
-----BEGIN PGP SIGNATURE-----
Comment: pub key http://matthew.vaneerde.com/pgp-public-key.asc

iD8DBQFBI6hlUQQr0VWaglwRAtX+AJ4nA+fccXix4IxnIC0YBiKr/6zxAACg3ecn
7T9kh1rJ+nj3i9Th0LOgxLw=
=R5bh
-----END PGP SIGNATURE-----



More information about the MIMEDefang mailing list