Stephen Frost writes ("Re: master's mail backlog and upgrade time"):
> *I* don't bounce much of anything. Talk to Ian about wanting to
> generate bounces, it wasn't my idea. What I want is for him to bounce
> it himself if he feels it needs to be bounced, not make master do it.
What I want is for master not to accept the mail either.
> Even with better SPAM checking on master it's very unlikely that
> master's policy will ever agree completely with Ian's (and everyone
> else's, whose policies are probably different from Ian's..) and so this
> kind of setup is unlikely to ever actually work (where you're depending
> on your forwarding hosts to implement the same policy you have).
In the modern internet you're always going to have some kind of
breakage due to this kind of policy mismatch. I'm familiar with this
problem myself because a significant proportion of my users use chiark
(with its strict spamfiltering) as a published email address and then
forward the email somewhere else; sometimes the somewhere else spots a
problem with a mail that chiark didn't spot and then I usually end up
dealing with bounced bounces. So the best idea is indeed for
downstream systems to have policies which are no more strict than
upstream systems.
But to elevate this to a _requirement_ on the users whose mail is
being forwarded presupposes that those users have a say in what that
mail flow is. I don't have an adequate say in the mail arriving for
me from master. There is no good reason why master should _ever_
accept mail for [EMAIL PROTECTED] from foreign systems.
I think `I would like this mail flow to go away completely' is a
perfectly reasonable position on the part of the user - at least, when
the user is a Debian developer and the mail flow is that directed from
strangers to their Debian account. And if the upstream system can't
implement that policy then it's reasonable of the user to implement it
themselves.
After we've got that far there are three things that the user can have
their system do to implement such a policy: 1. reject the mail at SMTP
time; 2. accept the mail, make a best effort at sending a bounce, and
if that fails discard the bounce; or 3. accept the mail and silently
discard it.
There are arguments in favour and against all of these options. None
of them are good but it is unreasonable to /demand/ that the user make
a particular choice. As it happens my arrangements currently imply a
mixture of 1 and 2 depending on the type of unwanted mail, with a
guesswork arrangement which attempts to show me mails which were
generated _on_ the Debian systems or by Debian sysadmins. But that is
a decision for me to take, surely.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
