From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/45908 Path: main.gmane.org!not-for-mail From: prj@po.cwru.edu (Paul Jarc) Newsgroups: gmane.emacs.gnus.general Subject: Re: new spam functionality added Date: Wed, 31 Jul 2002 17:35:08 -0400 Organization: What did you have in mind? A short, blunt, human pyramid? Sender: owner-ding@hpc.uh.edu Message-ID: References: <87y9brejam.fsf@mail.paradoxical.net> <873ctztyth.fsf@mail.paradoxical.net> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1028151407 10119 127.0.0.1 (31 Jul 2002 21:36:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 31 Jul 2002 21:36:47 +0000 (UTC) Cc: ding@gnus.org Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17a19C-0002d6-00 for ; Wed, 31 Jul 2002 23:36:46 +0200 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 17a181-0008Ft-00; Wed, 31 Jul 2002 16:35:33 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 31 Jul 2002 16:36:00 -0500 (CDT) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id QAA09617 for ; Wed, 31 Jul 2002 16:35:46 -0500 (CDT) Original-Received: (qmail 17271 invoked by alias); 31 Jul 2002 21:35:12 -0000 Original-Received: (qmail 17266 invoked from network); 31 Jul 2002 21:35:11 -0000 Original-Received: from multivac.student.cwru.edu (HELO multivac.cwru.edu) (@129.22.96.25) by gnus.org with SMTP; 31 Jul 2002 21:35:11 -0000 Original-Received: (qmail 15404 invoked by uid 500); 31 Jul 2002 21:35:31 -0000 Original-To: Scott A Crosby In-Reply-To: (Scott A Crosby's message of "31 Jul 2002 16:07:23 -0500") Mail-Copies-To: nobody Mail-Followup-To: Scott A Crosby , ding@gnus.org Original-Lines: 77 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i686-pc-linux-gnu) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:45908 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:45908 Scott A Crosby wrote: > Mailing list maintance functions (including initial requests to > subscribe, or confirmation requests from web-maintance.) either get > accepted automatically, (direct route for spam!), or force the > mailing list admin to deal with the automated 'please reply to me' > messages.. A well-behaved subscriber would add the MLM address to their whitelist before subscribing. List admins can feel free to drop confirmation requests from poorly-behaved subscribers. > Mailing list messages... Post to a mailing list the first time and > potentially get tens, hundreds, even thousands of 'please reply to > me' messages. I'm fairly certain that's false. TMDA sends its confirmation requests to the envelope sender, not From:, I think. MLMs rewrite the envelope sender. > Now, imagine there's a daemon that autoreplies to such 'please > reply to me' messages.. Actually, the replies can be automated, even safely, if the confirmation request includes the entire original message, or a checksum of it, so the autoconfirmer can verify that the user really sent the original message. > Well, just forge the spam to appear to come from a legitimate > user, and guess what, the bounces go to them, and their client > helpfully 'authenticates' the spam.. That's why there shouldn't be badly implemented autoconfirmers. But are there any? Anyway, this is not an argument against TMDA itself. > (The daemon can't be configured to record every email sent and > only autoreply to autoreplies to emails the user actually sent. Sure it can. But recording entire emails themselves wouldn't be the best way to do it. > Many times people will use many systems and email servers, but > only one email address.) A checksum scheme could still work in such situations. > For more fun, you may even get mail loops of 'please reply to me' > messages. If the confirmation request is sent from a dated address which does not itself require confirmation, there is no loop. Of course, if everyone starts using TMDA, spammers will quickly start guessing dated addresses. But then dated addresses will just evolve to be a hash of the date and a secret instead of just the date. > Under the assumption that there *will* be misconfigured clients, > they'll have to deal with mailing lists that they don't know > about. either by spamming posters to the list (unacceptable), or > filtering them out into a seperate folder that the user will have > to manually check. I'm not sure what you mean. > Of course the other option here is to spam from legitimate hosts > that have been cracked by today's IIS/outlook worm. (Or one of the > 30,000 *STILL* infected code-red machines.) The cracked systems run > email servers and reply automatically. Cracked systems can be abused even without TMDA in the picture. > TMDA and any other scheme that requires such automated response to > all sent emails is tragedy of the commons. TMDA doesn't require that unless you configure it that way. paul