From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/45917 Path: main.gmane.org!not-for-mail From: Scott A Crosby Newsgroups: gmane.emacs.gnus.general Subject: Re: new spam functionality added Date: 31 Jul 2002 17:35:51 -0500 Organization: Rice University Sender: owner-ding@hpc.uh.edu Message-ID: References: <87y9brejam.fsf@mail.paradoxical.net> <873ctztyth.fsf@mail.paradoxical.net> <87bs8nsh7g.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 1028154996 20759 127.0.0.1 (31 Jul 2002 22:36:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 31 Jul 2002 22:36:36 +0000 (UTC) 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 17a254-0005Oi-00 for ; Thu, 01 Aug 2002 00:36:35 +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 17a24j-000111-00; Wed, 31 Jul 2002 17:36:13 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 31 Jul 2002 17:36:39 -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 RAA09935 for ; Wed, 31 Jul 2002 17:36:25 -0500 (CDT) Original-Received: (qmail 19851 invoked by alias); 31 Jul 2002 22:35:53 -0000 Original-Received: (qmail 19846 invoked from network); 31 Jul 2002 22:35:53 -0000 Original-Received: from cs.rice.edu (128.42.1.30) by gnus.org with SMTP; 31 Jul 2002 22:35:53 -0000 Original-Received: from localhost (localhost [127.0.0.1]) by cs.rice.edu (Postfix) with ESMTP id 77EB24AA0B; Wed, 31 Jul 2002 17:35:52 -0500 (CDT) Original-Received: from sam.cs.rice.edu (sam.cs.rice.edu [128.42.3.145]) by cs.rice.edu (Postfix) with ESMTP id DB9454AA0A; Wed, 31 Jul 2002 17:35:51 -0500 (CDT) Original-Received: by sam.cs.rice.edu (Postfix, from userid 14314) id 82E12740DC; Wed, 31 Jul 2002 17:35:51 -0500 (CDT) Original-To: Josh Huber , ding@gnus.org Original-Lines: 93 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) X-Virus-Scanned: by AMaViS snapshot-20020300 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:45917 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:45917 On Wed, 31 Jul 2002 17:47:15 -0400, Josh Huber writes: > Scott A Crosby writes: > > > Because its tragedy of the commons, I bitbucket any TMDA user. (and > > if I start getting too many of em, I'll make a public blacklist of > > em.) > > Do you actually get a lot of confirmation requests? > Never, for which I'm glad.. But as its a bad idea in principal, I refuse to support it in any way. > > [snip lengthly example] > > I can see how you might think something like this would happen. There > are a few flaws in your example. (unless you assume many people have > misconfigured TMDA installations...but then why not assume they have > misconfigured MTA installations which spew duplicate messages all over > the place (or allow unrestricted relaying of messages)). TMDA is an end-user system, there will be misconfigurations of it, and bad reimplementations.. Hell, I got a vacation message from a message to this mailing list only an hour ago... After 20 years, you'd think they'd not be writing broken vacation programs anymore. > Most of your concerns are answered in the FAQ on the tmda site. > > 1. You will not get confirmation requests for posting to a mailing > list which has subscribers using TMDA. A confirmation request (if > any) would go to the *envelope sender* not the original sender (you). That either harasses the mailing list admin, gets posted accidently, or gets dropped (in which case, the user is likely to harass the mailing list admin for why the subscription request failed.) > Of course, no confirmation request will be sent because you would not > subscribe to a mailing list with TMDA using a bare (non-tagged) > address. Get it? The problem you describe with mailing lists just > does not happen. Sure.. I could configure TMDA to not act like an idiot. (well, mostly, I'd still screw up a little and harass some mail admins), but I'm not a typical user. > 2. "loops of please reply to me" -- this does not happen. Answer in > the FAQ: > > http://tmda.net/faq.cgi?req=show&file=faq04.012.htp ''If X uses his common sense, this won't happen.'' And what if X isn't aware of all the subtle issues? Which is what you'd expect from most people and implementations out there. Or, this is interesting: ''headers 'X-Delivery-Agent:.*TMDA' ok'' to auto-allow-TMDA messages through. So, start putting that on all of your email. > You really speak of absolute worst-case behavior in your complaint, This is not unfair.. 20 years later, they're still implementing bad vacation programs. > which isn't very fair. As an example, one of the authors of TMDA > mentions in the FAQ that approximately 6% of his correspondence is > asked for confirmation. I don't know.... if 6% of my outgoing email required confirmation, I'd be pretty annoyed. Autoreplying to one or two TMDA's a day costs me a lot more time than skimming my spam folder for accidental false positives. > I agree that making it harder than hitting reply is a bit much. I've > seen one instance where the recipient has you go to his web site and > fill out a CGI form describing the image displaed on the web page. > This is pretty sick, and going much too far IMO. Bitbucket em. :) Or better yet, put them in a public blacklist of 'morons'. > Anyway, my initial suggestion to put some text about TMDA in the > manual was just that -- a suggestion. I really don't want to start a > flame war here :) I should apologize.. I've just been reading too much about people lauding TMDA as being great. However, I think its a fundamentally bad idea; a perfect example of tragedy of the commons. Scott