Author: Tim Jackson Date: To: exim-users Subject: Re: [Exim] RE: Queue processing optimization
Hi Christian, on Fri, 20 Aug 2004 13:02:59 +0200 you wrote:
[lots of bounces being generated and frozen] > 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.
I don't believe that you have "no possibility" to verify the recipient
addresses. Even if your server is just a relay, you should do one of the
following:
a) if the "final" destination server rejects bad recipients at SMTP RCPT
time, use Exim's "callout" option i.e. "verify = recipient/callout" to
verify recipients on the destination server before accepting them. This is
very, very easy to implement and very effective as long as the destination
server isn't some piece of braindead trash like most versions of Microshit
Exchange (or, apparently, some/most/all configurations of qmail, based on
observed evidence), which are incapable of rejecting bad recipients at
SMTP time. However, from what you said originally, it does sound like your
downstream machines can correctly reject bad users at RCPT time.
b) find a way of transferring the list of valid users from whatever your
definitive database of users is (a passwd file on the destination server,
LDAP, whatever...) to the relay server. You can then use a simple Exim
lookup to verify valid users on the relay. This is a very fast and
efficient way of doing it, and it's definitely not rocket science. However
you store your users, there is a way to do it.
If you do not do any of the above, you are acting as a very bad mail
administrator. The reason is that for any mail which is sent to a bad
recipient at your domain, a bounce is generated (as you have observed).
Firstly, this wastes your bandwidth and resources. More importantly,
however, when spammers (or viruses) forge envelope senders, the envelope
sender often turns out to be a real, deliverable user - who had nothing to
do with the spam/virus. In that case, YOU will be needlessly spamming them
with bounces.
What you are seeing in terms of a large number of frozen bounces is a
symptom of this, and I'm glad it's happened because it's drawn this
problem to your attention. Trying to stop Exim freezing bounces is NOT the
solution, because it is not addressing the real problem; it's addressing a
symptom of it. The underlying problem is that you are needlessly
generating large volumes of bounces. In actual fact, your biggest concern
should not be the bounces that are undeliverable (and consequently
frozen), but the bounces which *ARE* deliverable, many of which will be to
unrelated third parties - in other words, you are spamming them.
So, don't accept bad recipients and you will find that both:
