Autor: Ian Eiloart Data: Para: exim-users CC: Philip Hazel Assunto: Re: [exim] Re: [exiscanusers] Exiscan for Exim-4.50?
>> BTW, at the exim conference I made a note to myself to find the exim >> bugzilla. Does that exist?
>
> It's being tested.
>
>> Or do I just send an mail this list asking for stuff to be added to
>> the wishlist?
>
> For now, yes.
OK, here are two wishlist items:
1. With the exiscan patch, and presumably with 4.50+, I can call arbitrary
scanning software by specifying the full path. I can pass a directory to be
scanned in the arguments.
I'd like to be able to pass a specific file name instead of a directory. I
think this would allow me to call Bogofilter at smtp time. Bogofilter requires
a filename, not a directory. The file would contain the complete email. I
suppose there may be other scanning solutions with a similar requirement.
2. Exim stops after a fixed period if it doesn't have access to a specific IP
address. I'd like to be able to specify the period in Exim's config, and even
to specify retry intervals.
I have a cluster of SMTP servers, using IPFailover on MacOSX. On startup, the
host machine has to recover its IP address from a failover host. Typically exim
starts within a few seconds of IP failback, but finds that its ports are not
available. I presume it is doing some sort of negotiation with the switch, but
I don't really understand what's going on here. What I do know is that exim
doesn't retry for 30 seconds - so I get an interval of up to 40 seconds total
where the IP address doesn't provide an SMTP service.
If I could tell exim to retry every second for a couple of minutes, then I
think the dead period would be roughly halved. There's a dead period during
failover of about three seconds.
More seriously, if the timeout occurs, and I fail back to a machine without
exim running, then I'm in big trouble. Therefore, I'd like to be able to have
exim to keep retrying essentially forever. If I could specify retry intervals
using the same syntax as for smtp retries, that would be excellent. It might be
more flexibility than I need, but it might just be easier to reuse the code,
and it might be better to stick with an existing syntax.
