Re: master's mail backlog and upgrade time
Stephen Frost writes ("Re: master's mail backlog and upgrade time"):
> * Andy Smith (andy@lug.org.uk) wrote:
> > a) inflict bounce spam scatter on the forged from addresses in the
> > malware and spam he doesn't want to accept delivery for; or
...
> It's his choice to do either (a) or (b) or (c). I couldn't care less
> which he does provided *he* does it. I do *not* want him to make master
> do (a) for him.
The problem with no-one sending bounces is that _legitimate_ mail
which is _mistakenly_ tagged as spam just vanishes.
If we want to have _reliable_ mail, ie mail which doesn't ever just
`vanish', we _must_, after accepting a mail, either deliver it, or
bounce it. If a system can't do either of those then the human system
administrator has to read them, or forward them to some other human
who will read them. That's my reading of RFC1123 section 5.3.3, and
would have been everyone else's before mass market ISPs started
throwing away bounced bounces en masse.
So if I have my system say `250' to a piece of mail, I'm guaranteeing
that either I'll bounce it (and get a `250' on the bounce), or that
some human (me or someone else I know) will read it.
The only practical solution to this problem in the modern environment
is to never accept mail that you don't want. Unfortunately master's
policies make it impossible for me to arrange to do that. I can do
what I can, though, and try to push the problem closer to the place
where it can be solved.
Ian.
Reply to: