Re: [Exim] RE: Queue processing optimization

On Fri, 20 Aug 2004, Christian Hertel wrote:

> > However you do it, just do it. Otherwise you end up accepting crap
> > claiming to be from innocent third parties, then later generating
> > a bounce -- thereby making yourself part of the problem.

> In our case, we have no possibility to verify either the sender
> address nor the recipient address (we only verify the domains),
> because it is just a mail relay server, not the server where the
> mailboxes are stored.

Please pay careful attention to the unattributed paragraph which you
quoted. You -ARE- making yourself part of the problem, and, unless
you show some enthusiasm for resolving that problem, by one or other
of the available mechanisms, then I think I can predict that you are
going to find little sympathy for any of your problems on this mailing
list.

> So here's another example:
>
> * Mail comes in from kjfbhjkhs@??? (Domain can be resolved, no
> possibility to verify the local part)

You mean like (lines wrapped for email):

2004-08-20 02:28:25 H=(yahoo1425.com) [218.61.75.213] sender verify
fail for <zgcom0408192007@???>: response to "RCPT
TO:<zgcom0408192007@???>" from mx2.mail.yahoo.com
[64.156.215.8] was: 553 VS10-RT Possible forgery or deactivated due
to abuse (#5.1.1)

Most certainly there is a chance to reject it in that way, as you can
see (it won't always work, but it's better than nothing).

But this isn't going to solve /your/ problem, because spammers and
viruses also counterfeit *genuine* addresses as their sender.

> * Mail recipient is blablabla@??? (Domain is ok, we relay
> mail to it but again no possibility to verify the local part because
> the mailbox is stored on another server)
>
> * The destination mailserver rejects the mail in the smtp dialog
> with an '554 User unknown error', so generating the bounce message
> is our part.

You -must- stop doing that, or you really -are- part of the problem.

> * Our bounce message could not be delivered to kjfbhjkhs@???
> because the yahoo mailserver rejects it in the smtp dialog again
> with an '554 User unknown' error.

Fine. This is working as designed.

> BUT - and that is the bad thing - our bounce message is not
> discarded but frozen by exim and held in our mailqueue.

No, the *really bad* thing is that you haven't yet grasped what you've
already been told, about making yourself part of the problem.

You *must* take more effort to stop accepting this crap in the first
place.

What you seem to have missed is that it's much worse when you
accept mail for a non-existent addressee which has counterfeited a
*real* sender address. You think everything's nice because you get
the bounce out of your hands and don't see the problem. But the poor
sucker whose address is counterfeited as envelope sender on spams and
viruses thousands of times a day is far from amused, and you're going
to find your server blacklisted if you do it too often.

good luck