Re: new spam functionality added

[Scott A Crosby <scrosby@cs.rice.edu>]

On Wed, 31 Jul 2002 17:47:15 -0400, Josh Huber <huber+dated+1028582805.6306a1@alum.wpi.edu> writes:

> Scott A Crosby <scrosby@cs.rice.edu> 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