thats bad. Any reason for it?
> Obviously whatever method you use will have to be supported both by the client
> (the proxy) and server (exim).
Well, the Proxy does support XCLIENT, exim does not. And a switch to
Postfix wouldn't be possible in a short term.
> It also depends on whether you want exim to really believe that it is
> connected directly to the original sender (not the proxy), or whether simply
> /knowing/ the original sender's IP is good enough.
Well, the proxy works fine. But it is closed source. Only one program
can listen to port 25 on our smtp server. As the spamfilters detection
rates are decreased when using as a spamd replacement (since envelopes
and sender ip aren't available in the spamd protocol) it has to be used
as proxy. But that way, the greylisting and RBL features of exim cannot
be used, since the original ip isn't known to exim. There is no other
way than to pass it to exim. XCLIENT is the known extension for it.
xtext extensions are described in RFC 1891. Since exim runs on a
separate server and the port is firewalled, I can be absolutely sure,
that only our proxy can deliver to exim.
> You could configure exim to expect the client IP in a HELO/EHLO line, or maybe
> (ugh) an AUTH line.
1. The proxy is closed source, so I cannot change anyhing
2. If the HELO line is misused to transport the sender ip, where goes
the original HELO line then?
Why doesn't exim support XCLIENT? Was the issue discussed be the
developers? Or did noone start to implement it?
