been going through the TCP dump i got from one of the failures ...
haproxy (syn) ---------------> exim
exim (syn,ack) ---------------> haproxy
haproxy (ack) ----------------> exim
exim (banner) 3s later ---------> haproxy
haproxy (proxy line) ---------> exim
exim -----------------------> haproxy
so not sure if its exim or haproxy at this point .. will need to compare
with a working conversation .. but from my understanding the proxy line
should be pre-banner ... but whether is haproxy not sending it in
sequence or exim jumping the gun ... from hosts NOT on the proxy_host
list things still work ok.
still even so should this be a solid 5xx reject or a 4xx defer when this
issue happens .. for a client 5xx is nice but for mx server 4xx would be
nicer ie defer as temporary issue and defer rather than bounce.
rgds
Matt B.
On 27/02/2015 7:18 pm, Phil Pennock wrote:
On 2015-02-27 at 15:37 +1000, Matt Bryant wrote:
Is anyone using this in anger yet ??? Been doing some testing and most
of the time it works ok but there are occasions when 'Proxy Negotiation'
fails, give the ha proxy VM a quick reboot and starts working again .
which is kinda strange.
I believe that Todd Lyons, the Exim maintainer who wrote the support, is
using it.
Note that if things work when you reboot the bit which isn't Exim, then
that suggests that some state has shifted on that box and that if you
didn't touch Exim when you rebooted the other one, then Exim is not in a
bad state and is continuing to work in the same way it was before.
At this point, log-files from Exim and from the HA box at the point in
time when the failures latch on would be good to see.
-Phil
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
