On Tue, Nov 02, 2004 at 03:10:31PM -0500, David Brodbeck said:
> > -----Original Message-----
> > From: Tore Anderson [mailto:tore@linpro.no]
>
> > Here's a quote from a discussion I had about this very
> > topic with one
> > of the people behind postmaster@???, a perfect example of the
> > person I said would hate you above:
> >
> > ??do you think I'm wound up about this for fun? or maybe
> > it's because
> > debian.org postmaster address is now basically fucking
> > useless thanks
> > to the combination of a) fuckwits with AV filters, and b) fuckwits
> > with 550-ing afer DATA??
> >
> > That's verbatim, by the way.
>
> Sounds like a configuration problem. I don't know why anyone would route
> failed bounce messages to postmaster. Here they get flushed out of the
> queue after a couple hours if they can't be delivered. I learned very
> quickly that a failed bounce is almost always triggered by spam. It's
> unlikely to contain any useful information.
That was my take on that too. Debian.org does a LOT of mail forwarding
since most accounts just are aliases. Why they would want the postmaster
account do deal with all those delivery problems is beyond
understanding. There are other mechanisms to deal with bounce problems
as every mailing list manager should be aware of. Exim just makes it
easier. :-)
That particular postmaster's stance is understandable, but it should be
painfully clear to him that the current situation / configuration isn't
working well for him. With all due respect to that nameless postmaster,
the current situation we have today with spam and viruses is untenable
and rejecting at smtp time is really the best overall way to handle it.
> I consider refusing mail at SMTP time a far better solution than the other
> two options: Accepting it and then bouncing, or sending it to /dev/null.
> The former creates far more backscatter spam, the latter means that sooner
> or later a real message is going to get trashed and no one will hear about
> it.
Yep. Looking at my own logs, I would create 1000 times more bounces and
collateral damage if I did it any other way. /dev/null is not a
realistic option and is probably the worst solution from a reliability /
good customer service point of view.
