} > The current value of the default is a 60 second timeout. Perhaps
} > reducing this to, say, 30 would help in some cases?
}
} I suspect you may have missed a subtle bit which hasn't been explicitly
} mentioned, just eluded to ...
}
} With the correct setup of firewalls and old O/S code, the effect is that the
} callback generates a "host unreachable" which causes the O/S to close all
} calls to that host -- including the SMTP call !
I'd hesitate to say that it is a correct firewall setup... rejecting
or dropping is one thing, saying that the host is unreachable is
different :-)
The number of OSes affected by this particular problem is definitely
very low now. Its the OS running exim that is the problem, and I
haven't seen configs for nay of the duff ones I know about.
} It's not just the brain dead PC problem of accepting but not replying :-(
Ah - that can be the result of a firewall too!
However I think our timeout lies somewhere else entirely. The code
in libident is roughly
connect()
select(,,,timeout)
read()
ie it connects *then* applies the timeout. connect of course has its
own set of timeouts. I think we should take this up with Peter
Eriksson (the author of libident), and see about doing something more
like
alarm() {
connect()
select(,,,timeout) -- optional
read()
}
[OK, its not C, but I'm working in concepts rather than code :-) ]
The problem is that you presumably have an alarm active already for
the SMTP timeouts. This could be coded around, however.
Also you might want to look at rfc931.c from Wietse Venema's TCP
wrappers.
Nigel.
--
[ Nigel.Metheringham@??? - Unix Applications Engineer ]
[ *Views expressed here are personal and not supported by PLAnet* ]
[ PLAnet Online : The White House Tel : +44 113 2345566 x 612 ]
[ Melbourne Street, Leeds LS2 7PS UK. Fax : +44 113 2345656 ]
