Mark Constable writes:
On 18/04/12 09:18, Sam Varshavchik wrote: >> So is the bottom line there is no way for courier to provide a binding to >> the virtual interface so that it would pass SPF checks without having to>> add the default eth0 IP of 206.221.219.122 to the SPF record for eth- os.org?> > If you're looking to have /all/ outgoing mail sent from a socket that's > bound to that IP address, this would be the SOURCE_ADDRESS > (or SOURCE_ADDRESS_IPV6) setting in the courierd configuration file.No, not /all/ outgoing mail via any one single SOURCE_ADDRESS, I have been doing that for quite a while.That postfix config example allowed for MULTIPLE bindings to MULTIPLE IPs witheach providing it's own outgoing hostname and SSL certificate.
You're using client certificates to authenticate your outbound SSL connections? This would only be necessary, or meaningful, if you're doing this to connect to a smarthost. Except for a smarthost that demands you to authenticate yourself, nobody is going to care about your certificate, or even bother to ask you for one. Client side certificates, which is what you're talking about here, are sent only if the server asks the client for it.
And if you're using a smarthost, the smarthost should be authenticating you by an IP address. If it's authenticating you by a certificate, it will not care what IP address you're using, for your certificate, or what the certificate is, as long as it's a certificate that's signed by the right CA.
Furthermore, if that smarthost is authenticating you, it's not going to care about SPF, or any of that jazz. The only possible way that SPF would matter in this situation would be if some relay further down the road is stupid enough not to simply use an SPF check for its direct connection, but attempt to dig into the existing SPF records that are already in the message, parse the identifying info out of them, and attempt to run an SPF check on that.
Either I'm missing something fundamental, or this is the craziest thing I've heard in a long time. Yes, SPF is broken with regards to mail forwarding, but attempting to compensate for that by ripping apart the existing Received: headers in a vain attempt to make sense of the nonsense, is just replacing this inherent broken-ness with double, or even triple-brokenness.
And how exactly is Postfix selecting which outbound IP address to use here, anyway.
That was the "magic" according to the subject of this thread. What about the possibility of running separate instances of courier each with it's own SOURCE_ADDRESS and set of config files?
Well, there's always that option.But I think I'm still missing some part of the picture here. In general, Courier does not really have much sophistication in terms of outbound mail. Either it leaves it up to your server to figure out the outbound IP address, according to its routing tables, or you can force it to use a specific IP address. If you want it to use SSL, if available, you can give it a certificate, if the other server will ask for it. That's pretty much it. Right now, that's all that can be done. It wouldn't be that complicated to write some more code here, I suppose, but I just don't understand why it's needed, and what exactly it would want to do, and why.
------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
pgpbOECp952I6.pgp
Description: PGP signature
------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
