[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#164344: Bug#160529: (ITP of ASK) should not be packaged



[Nuking 160529-quiet from CC list; it's pointless to mail a bug and the
same bug's -quiet address.]

On Thu, Oct 07, 2004 at 10:25:06PM -0400, Marco Paganini wrote:
> > See also the mailloop this package created here:
> > 
> > http://lists.debian.org/debian-boot/2004/08/thrd5.html#02087
> > 
> > (750 mails at a very fast rate to a mailinglist with well over 500
> > subscribers, meaning ~400.000 spam-caused autoresponses in half a day),
> > and, see also the opinion of Branden Robinson on this software:
> > 
> > http://lists.debian.org/debian-devel-announce/2004/08/msg00015.html
> 
> Notice that this mail-loop was created by a clueless user inserting the
> mailing-list address on the "blacklist" (something that we urge users not to
> do). There is really no protection against this kind of behavior. A similar
> situation can happen for many reasons, including a badly configured procmail
> rule, for instance.

Of course there is protection against it.

Each message that ASK sends out should include a cookie, consisting of the
hash of a characteristic of the message plus a local secret that can stay
invariant on a per-installation basis.

You can use a simple symmetric encryption algorithm using the local cookie
plus the message's unique identifier (the Message-ID would work well if you
create that yourself per the appropriate RFC) as a key.  You encipher the
same message for every outbound ASK mail, for instance: "THIS MESSAGE
GENERATED BY ACTIVE SPAM KILLER."

When you get a purported ASK message back, you have the ciphertext, and the
message-specific part of the key in plaintext alongside it (e.g., the
Message-Id).

You then attempt to decrypt the message using your local cookie plus the
plaintext key component.  If you get back the desired plaintext, then you
know you got one of your own messages back.

Otherwise, you know you either got some other ASK's message, or that you're
under attack.

The local key and the encryption algorithm don't have to be very strong to
be effective.  I wouldn't use something as simple as XOR, though, because
you'd be using the same plaintext all the time and a known-plaintext attack
is obvious.

These techniques are very, very old.

-- 
G. Branden Robinson                |      It doesn't matter what you are
Debian GNU/Linux                   |      doing, emacs is always overkill.
branden@debian.org                 |      -- Stephen J. Carpenter
http://people.debian.org/~branden/ |

Attachment: signature.asc
Description: Digital signature


Reply to: