--vhlPM4nsAjMnZaDZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[Please don't Cc me on responses to posts to public mailing lists.
I read the mailing lists. Note that I do actively set a
Mail-Followup-To: header to indicate my preferences on this point.]

On Thu, Mar 04, 2004 at 08:43:44PM -0500, Greg A. Woods wrote:
> Keep in mind that the issue is with _forged_ bounces.

This is all a bit out of date now, but that's not how I read the
description of the problem at the time. I read it as "spam was sent
from the mailing list's Return-Path to some subscriber, which the
subscriber's MTA bounced back to the mailing list, which resulted
in unsubscription".

I don't quite understand how things could be any different than
that. Is the mailing list software in question really so stupid as
to be unable to tell the difference between the recent "pretend to
be a bounce message" Windows viruses and real bounces? (They don't,
in fact, look at all the same, except in Microsoft Outlook...)

> It's not always that simple.  Consider what happens when anyone uses an
> alias or ~/.forward file on some other system to forward their mail to
> their primary or "home" system, and then somewhere along the line the
> message is rejected at SMTP time, or worse an intermediate filter that's
> not so well designed and implemented causes a new bounce message to be
> generated.

Okay, so it is what I thought it was. That's brokenness on the
user's end (they *are* in fact sending bounce messages to a forged
Return-Path as a result of spam sent to them), and they deserved to
be unubscribed, in my view, since they're only contributing to the
bandwidth wasted by spam.

> That's not always the right thing to do, and certainly never with
> anything that isn't guaranteed with 101% certainty to be spam or
> malicious content, and even then it's _much_ better to reject it at SMTP
> time than to accept and then drop it.

If you can't be sure it's spam, then you deliver it, but don't read
it promptly.

If you can be sure it's spam, you can also be sure that sending an
automated response won't help anything.

Under what circumstance would it ever be reasonable to send an
automated response to something that's probably spam?

--=20
gabriel rosenkoetter
gr@eclipsed.net

--vhlPM4nsAjMnZaDZ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFAR92B9ehacAz5CRoRAmjQAJ459WfXZI65a0BrTWSx+wbrs7XR1QCfSeww
hZ18tTuS/18CC/OWmUsmvhA=
=/2G+
-----END PGP SIGNATURE-----

--vhlPM4nsAjMnZaDZ--