Re: [exim] problem of understanding of unseen, self=pass and…

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: W B Hacker
Data:  
Para: exim users
Assunto: Re: [exim] problem of understanding of unseen, self=pass and more
Marten Lehmann wrote:

> Hello,
>
> > If it hits the end of the routers without
>
>>matching another then it will bounce back as unrouteable, as it believes
>>it has not matched because it was set as unseen.
>
>
> right.
>
>
>>Stuarts suggestion is
>>your best option to make sure all routers are processed (all other
>>routers set us unseen)
>
>
> Ok, but this means, that the master router at the end of all routers
> needs to have a huge condition combining all conditions of previous
> routers. Have you ever worked with nested and{}s and or{}s? It's a pain
> in the a**. Otherwise the last router could simply accept all mail, but
> if you are operating a mailserver I hope you aren't doing this, because
> then you get flooded with mails from bots, zombie pcs and so on.
>
> What I need is something that works like "unseen" (so further routers
> are tried), but that remembers if the router has matched and is
> continuing anyway but will accept the message without a final master router.
>
> Regards
> Marten
>


*Eventually* when done testing, we will get all the glitches in our own router
chain finalized.

*Meanwhile* - instead of using 'require verify = recipient' to walk a still
under-construction chain in 'verify' mode, we put a simple callout [1] ahead of
it to accept valid // reject invalid recipients.

As the 'leaky' routers are eat-anything-on-their-plate archivers anyway, nothing
is actually 'lost', just maybe in need of an 'mv' or 'cp'.

Not recommended for volume production, but can buy you time to sort the routers
in a more measured manner. Test, check logs and mailstore, alter, repeat.

Bill

[1] Flat file or CDB would do fine. We actually use a 'not so simple' SQL call.