On 2012.04.20 06:36, Sam Varshavchik wrote:
> Yes, well, it's really more than just that. I now understand what's
> going on here, and there's a bit more stuff here in play. You can listen
> on multiple IPs just fine. What also needs to be done is also to save
> which IP address each message was received from, and then use that IP
> address in case that message ever goes out via SMTP again, in addition
> to using an IP address-specific configuration.
> And, of course, the fact that Courier pipelines outbound SMTP, which
> means a disconnect and a reconnect. I don't think I'll want to set that
> as a different SMTP destination. Too much stuff depends on the SMTP
> destination identified by the destination domain.
> And then there's the server name TLS extension, where you do not need a
> different IP address in order to select the right certificate (if the
> client is agreeable to negotiating that TLS extension). But that only
> works if Courier gets compiled against GnuTLS rather than OpenSSL,
> because last time I checked only GnuTLS supported that TLS extension,
> and OpenSSL didn't, so support for that is only there when you build
> Courier against GnuTLS. So now you've got a message to send on behalf of
> an IP-less domain. Now what are you going to do, then.
> But, let's see what I can do.
Sam, could you please make binding to the same ip address optional.
I have several setups where SMTP server has both public and RFC 1918
addresses but is not serving as an IP gateway for other private network
hosts (i.e. is just an SMTP gateway). If courier will start to allways
bind to the same ip address, I will need extra NAT/filter rules for both:
- emails that come from inside and addressed to servers outside;
- and emails from outside, forwarded to other email server on the
GM Consult Group, UAB