Bug#164344: Bug#160529: (ITP of ASK) should not be packaged
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Oct 15, 2004 at 01:06:04AM -0500, Branden Robinson wrote: >> ASK has a whitelist, an ignorelist and a blacklist. The blacklist sends back >> a "nastygram" informing the user that we do not want to receive further >> messages from him/her. Unfortunately (and yes, this is my fault), I never >> imagined someone would add a mailing-list to his blacklist (sounds just too >> insane, doesn't it?). Well, it happened, and I'm now dumping the blacklist >> feature entirely to protect the community from people who use it incorrectly. > >My original rant was based on two things: > >1) You seemed to be unaware of a certain lesson from history[1]. >2) Anything that claims to be a "spam killer" is going to attract > apoplectic and irrational people who will stop at nothing to sate their > desire for vigilante justice against spammers. Many of these people are > simply not mature enough to take into account the innocent bystanders > they may inconvenience by using your software to vent their spleens. > In my opinion, it was poor judgement on your part to hand people this > sort of loaded weapon. People *will* be insane. People *will* be > stupid. I realize you've already acknowledged that this was an error on > your part -- I am not trawling for an apology. > >I would withdraw my objection if ASK as packaged in Debian will omit >whatever part of the code autoreplies with a nastygram. If dropping the >blacklist entirely will achieve that, then that's fine with me. That's the intention. I'll be releasing beta 2.5.1 soon, already without the blacklist "nastygram" feature. Email addresses in the blacklist will be automatically ignored, of course. This should keep a reasonable degree of backwards compatibility while minimizing this kind of situation. I take any email loop possibilities very seriously. Despite Karsten's "paper" saying otherwise, ASK has protection against mail loops and it will also do all kinds of heuristics to prevent the confirmation from being sent to a mailing-list. Of course, nothing can be done against spoofed addresses. If someone spoofs your address, you will receive a confirmation challenge, even though you never sent the original email. This, unfortunately, is a problem with SMTP and there is nothing that can be done about it with the current technology. I, for myself, receive tons of "mailer-daemon" bounces from spammers and virii. Honestly, I don't think ASK adds too much to the problem. >I don't want to try to micromanage how your code is written or how its >eventual Debian package maintainer does his or her job -- my position is >simply to exhort people (as strongly as I need to) not to make it easy for >idiots to attack Debian's mailing lists. Things that send automatic >replies to mail messages is, if not designed for abuse, easily perverted to >it -- if one doesn't take fairly elaborate precautions like the one I >described. I understand your position, and believe me, I agree with it. Regards, Paga - -- Marco Paganini | UNIX / Linux / Networking [EMAIL PROTECTED] | PGP: http://www.paganini.net/pgp/ http://www.paganini.net | Magnus Frater te spectat... -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBcbkJL2FWjNfH2XwRAqJRAJ9BSFHRhiOeLKYT1jmEbd3NI4eqZQCeNy7/ urj186cJh/UG5OTHKIjkMGc= =tGuV -END PGP SIGNATURE-
Bug#164344: Bug#160529: (ITP of ASK) should not be packaged
On Thu, Oct 14, 2004 at 06:06:19PM -0400, Marco Paganini wrote:
> On Thu, Oct 14, 2004 at 03:25:54PM -0500, Branden Robinson wrote:
[...]
> >Of course there is protection against it.
[my scheme deleted]
> This is a good idea, and implemented to some degree in ASK. The problem is
> that *nothing* is guaranteed to survive a reply. Adding a cookie to the body
> of the email is not 100% foolproof, as there's no guarantee that the reply
> will contain the cookie. Adding a specific header with the cookie will also
> take us nowhere, as headers mostly discarded in replies. One option is the
> Message-ID header, but my experiments showed that a large population of MUAs
> (many versions of MS Out-Of-Luck, for instance) trash the Message-ID and
> don't put it in the "In-Reply-To" field when responding to an email.
I was afraid you'd say something like this. :(
> The only "guaranteed" way to know if an email is a reply to something you
> sent is to use VERPs, but this creates enormous difficulties for users that
> do not have full email control in their servers (users).
Acknowledged.
> In any case, the original problem with the mailing list has nothing to do
> with this, but rather with insanity of one of ASK's users.
>
> ASK has a whitelist, an ignorelist and a blacklist. The blacklist sends back
> a "nastygram" informing the user that we do not want to receive further
> messages from him/her. Unfortunately (and yes, this is my fault), I never
> imagined someone would add a mailing-list to his blacklist (sounds just too
> insane, doesn't it?). Well, it happened, and I'm now dumping the blacklist
> feature entirely to protect the community from people who use it incorrectly.
My original rant was based on two things:
1) You seemed to be unaware of a certain lesson from history[1].
2) Anything that claims to be a "spam killer" is going to attract
apoplectic and irrational people who will stop at nothing to sate their
desire for vigilante justice against spammers. Many of these people are
simply not mature enough to take into account the innocent bystanders
they may inconvenience by using your software to vent their spleens.
In my opinion, it was poor judgement on your part to hand people this
sort of loaded weapon. People *will* be insane. People *will* be
stupid. I realize you've already acknowledged that this was an error on
your part -- I am not trawling for an apology.
I would withdraw my objection if ASK as packaged in Debian will omit
whatever part of the code autoreplies with a nastygram. If dropping the
blacklist entirely will achieve that, then that's fine with me.
I don't want to try to micromanage how your code is written or how its
eventual Debian package maintainer does his or her job -- my position is
simply to exhort people (as strongly as I need to) not to make it easy for
idiots to attack Debian's mailing lists. Things that send automatic
replies to mail messages is, if not designed for abuse, easily perverted to
it -- if one doesn't take fairly elaborate precautions like the one I
described.
Thanks for your patience.
[1] From Jargon File (4.4.4, 14 Aug 2003) [jargon]:
ARMM
n.
[acronym, `Automated Retroactive Minimal Moderation'] A Usenet
{cancelbot} created by Dick Depew of Munroe Falls, Ohio. ARMM was
intended to automatically cancel posts from anonymous-posting sites.
Unfortunately, the robot's recognizer for anonymous postings
triggered on its own automatically-generated control messages!
Transformed by this stroke of programming ineptitude into a monster
of Frankensteinian proportions, it broke loose on the night of March
30, 1993 and proceeded to {spam} news.admin.policy with a recursive
explosion of over 200 messages.
ARMM's bug produced a recursive {cascade} of messages each of which
mechanically added text to the ID and Subject and some other headers
of its parent. This produced a flood of messages in which each header
took up several screens and each message ID and subject line got
longer and longer and longer.
Reactions varied from amusement to outrage. The pathological messages
crashed at least one mail system, and upset people paying line
charges for their Usenet feeds. One poster described the ARMM debacle
as "instant Usenet history" (also establishing the term {despew}),
and it has since been widely cited as a cautionary example of the
havoc the combination of good intentions and incompetence can wreak
on a network. The Usenet thread on the subject is archived here.
Compare {Great Worm}; {sorcerer's apprentice mode}. See also
{software laser}, {network meltdown}.
--
G. Branden Robinson|
Debian GNU/Linux | Ignorantia judicis est calamitas
[EMAIL PROTECTED] | innocentis.
http://people.debian.org/~branden/ |
signature.asc
Description: Digital signature
Bug#164344: Bug#160529: (ITP of ASK) should not be packaged
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Branden, On Thu, Oct 14, 2004 at 03:25:54PM -0500, Branden Robinson wrote: >> 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). This is a good idea, and implemented to some degree in ASK. The problem is that *nothing* is guaranteed to survive a reply. Adding a cookie to the body of the email is not 100% foolproof, as there's no guarantee that the reply will contain the cookie. Adding a specific header with the cookie will also take us nowhere, as headers mostly discarded in replies. One option is the Message-ID header, but my experiments showed that a large population of MUAs (many versions of MS Out-Of-Luck, for instance) trash the Message-ID and don't put it in the "In-Reply-To" field when responding to an email. The only "guaranteed" way to know if an email is a reply to something you sent is to use VERPs, but this creates enormous difficulties for users that do not have full email control in their servers (users). In any case, the original problem with the mailing list has nothing to do with this, but rather with insanity of one of ASK's users. ASK has a whitelist, an ignorelist and a blacklist. The blacklist sends back a "nastygram" informing the user that we do not want to receive further messages from him/her. Unfortunately (and yes, this is my fault), I never imagined someone would add a mailing-list to his blacklist (sounds just too insane, doesn't it?). Well, it happened, and I'm now dumping the blacklist feature entirely to protect the community from people who use it incorrectly. Regards, Paga - -- Marco Paganini | UNIX / Linux / Networking [EMAIL PROTECTED] | PGP: http://www.paganini.net/pgp/ http://www.paganini.net | Magnus Frater te spectat... -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFBbvhaL2FWjNfH2XwRAi8RAJ95GWsVh1VXLAY1+dV1KVzsL0v+ZQCePUrs AD287f/yXBWkspLE39jayKQ= =zbzz -END PGP SIGNATURE-
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. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#164344: Bug#160529: (ITP of ASK) should not be packaged
> 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. Regards, Marco Paganini > > --Jeroen > > -- > Jeroen van Wolffelaar > [EMAIL PROTECTED] > http://jeroen.A-Eskwadraat.nl -- Marco Paganini | UNIX / Linux / Networking [EMAIL PROTECTED] | PGP: http://www.paganini.net/pgp/ http://www.paganini.net | Magnus Frater te spectat...
