Auteur: David Woodhouse Datum: Aan: Chris Bayliss CC: exim-users, Sean Hoggard, Nigel Metheringham Onderwerp: Re: [exim] Newbie spam bounce retries question (without disclaimer)
On Tue, 2004-09-14 at 16:40 +0100, Chris Bayliss wrote: > The original point was not that you may become some part of some problem, but
> that you were unlikely to be breaking the computer misuse act, which an earlier
> poster had suggested. You don't _know_ that the _third_ party is _innocent_
> anyway.
You don't _know_ but you do have a fairly good idea that the third party
is innocent, in the majority of cases.
> 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?
> > legitimate sender will get a bounce, while a drone sending spam will
> > just move on to the next victim.
>
> Unless its come through a relay, in which case the only difference between
> a non delivery report an a rejection is that one will give more idea
> of what is going on.
Not all of it (perhaps not even most of it) comes through open relays
-- and if it's come through an open relay then the sender can use
blacklists to reject the bounce. They cannot do that if _you_ send the
bounce for yourself.
> We do reject rather than generate NDRs in the vast majority of cases,
> but things aren't as black and white as you make out and sometimes for
> a whole variety of reasons its not always practical to reject.
So you'd prefer to cause inconvenience to innocent third parties in
order to make life easier for those who have a broken setup which
doesn't correctly convey the SMTP error messages? I find your choice of
priorities interesting.
