Re: [Exim] Final Peer Review Sought: "Spam Filtering for MXs…

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Tor Slettnes
Fecha:  
A: Exim Users' Mailing List
Asunto: Re: [Exim] Final Peer Review Sought: "Spam Filtering for MXs" HOWTO
On Jul 11, 2004, at 04:59, Matthew Byng-Maddick wrote:
> On Sat, Jul 10, 2004 at 10:05:25PM -0700, Tor Slettnes wrote:
>> On Jul 9, 2004, at 01:59, Matthew Byng-Maddick wrote:
>>> This shouldn't be "hash_8", it should be something more along the
>>> lines of:
>> Any particular reason?
>
> That the secret can almost certainly be reversed out from the string,
> and
> new valid return paths predicted. Given that you're writing a HOWTO, it
> seems sensible to use something safe to start with, rather than
> suggest to
> people to do something unsafe.


I'll make this change to please you. :-)

I still have to say that I don't completely agree. For someone to be
able to deduct your SECRET from a "${hash_N:SECRET=<string>}" (where N
is smaller than the length of "SECRET=<string>"), they would need:
- samples of several different signatures - in other words - they
would have to solicit or gather mail that you sent to several different
recipients.
- a pretty good understanding of Exim's ${hash..} function

From a spammer's perspective, they would have to spend a lot of effort
trying to crack ONE potential recipient's secret. Although economics
of scale applies, it would be very difficult for them to be able to
efficiently gather the number of mails they require for each recipient
to be able to generate such a key.

Finally, the document already contains the following blurb:

  <para>
    Note that we use Exim's <option>${hash ..}</option> function
    to generate the signature.  This is not cryptographically
    safe (it would be possible, with a few samples of your
    outgoing mail, to discover your <option>SECRET</option> -
    however, for the purpose of defeating spammers, this should
    be more than enough.  If you are paranoid about this, you
    could consider a <option>${hmac{md5}{SECRET}{...}}</option>
    expansion instead - but the generated signature will be much
    longer.
  </para>



That said, I am not terribly interested in leaving this as a lingering
issue in the reader's (or your) mind, and as I said, will change the
the document to use ${hmac...} instead (truncated with ${length..}, as
you suggest).

-tor