Autor: David Woodhouse Data: Para: Chris Bayliss CC: exim-users, Sean Hoggard, Nigel Metheringham Asunto: Re: [exim] Newbie spam bounce retries question (without disclaimer)
On Tue, 2004-09-14 at 16:53 +0100, David Woodhouse wrote: > On Tue, 2004-09-14 at 16:40 +0100, Chris Bayliss wrote:
> > There _are_ cases when you need to let the sender know what is going on
> > and what they can do about it. A refusal won't do this much of the
> > time, because any message generated as part of the SMTP dialogue
> > doesn't reach the real sender in the majority of cases. More often
> > than not all that many of them see is the rejection with an
> > interpretation of why it may have failed instead of any errror message
> > that you may have generated.
>
> I find 'in the majority of cases' and 'More often than not' hard to
> believe. Yes, there are broken setups out there which obliterate such
> information -- but a _majority_? I suspect not. Is this the experience
> of others? Have I just led a sheltered life?
Setting aside the question of how many systems out there are broken in
this way -- how many users actually read the message _anyway_?
In my experience, users _don't_ read bounce messages. At best, they just
forward them to the local geek/sysadmin/boyfriend with a note saying
"Why didn't this work?". At which point said geek/sysadmin/boyfriend
either looks at the mailer logs or just reads the forwarded bounce,
pasting precisely what it originally said back into a reply, only
without the 'This is an automatically generated message' prefix which
caused the original user to be unable to read it in the first place.
But that's at _best_. More often than that, the user will delete the
bounce, then mention it in passing three days later. At which point the
_only_ recourse is to trawl through the logs looking for a bounce which
happened on 'Thursday morning some time'; looking first for a bounce
generated locally and then finally realising that the mail _did_ go
through and the bounce was generated remotely by some misbehaving system
which shouldn't have accepted a mail it didn't like in the first place.
And all you have in the logs is the original acceptance followed by a
bounce, with _no_ information about why it happened.
Thus, your stated policy would seem to be counterproductive -- it
_hides_ the information about what happened, in the case which in my
experience is the most common.
