[Exim] RE: Queue processing optimization

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Christian Hertel
Fecha:  
A: exim-users
Asunto: [Exim] RE: Queue processing optimization
--
Hi again,


> > I implemented a recipient lookup at RCPT time and refuse unknown
> > recipients right on the doorstep. This of course requires knowledge
> > about the user base on the relayed-to domains. We solved that by
> > generating a flat recipient list every night via one or more ldap
> > queries against the relayed-to domains. Of course if you cater for

250
> > 000 users this may be sub-optimal...
>
> 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.
>
> You should ideally also do sender verification -- why accept the mail

in
> the first place, if you can't send a bounce to the address it claims

to
> come from?


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.

So here's another example:

* Mail comes in from kjfbhjkhs@??? (Domain can be resolved, no
possibility to verify the local part)

* 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.

* 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. BUT - and that is the bad thing - our bounce
message is not discarded but frozen by exim and held in our mailqueue.
This happens thousand times so thousands of bounce mails were held in
our mailqueue although they could never be delivered. Permanent means
'forget it, you could NEVER be deliver the mail'.


--
Christian Hertel
Technik

infoServe GmbH
Nell-Breuning-Allee 6
D-66115 Saarbruecken

T: (0681) 8 80 08 - 0
F: (0681) 8 80 08 - 33
www.infos.de
E: c.hertel@???
--
Content-Description: Dies ist ein digital signierter Nachrichtenteil

[ signature.asc of type application/pgp-signature deleted ]
--