Mark Constable writes:
eth0 = xx.xx.xx.1 = primarydomain.com = esmtpd.pem eth0:0 = xx.xx.xx.10 = vdomain0.com = esmtpd.pem.xx.xx.xx.10 eth0:1 = xx.xx.xx.11 = vdomain1.com = esmtpd.pem.xx.xx.xx.11 eth0:2 = xx.xx.xx.12 = vdomain2.com = esmtpd.pem.xx.xx.xx.12 [...] The above works fine with courier when clients use these domainnames as outgoing mailservers on port 465, they get the right certificate without any errors. I'm not familiar with postfix either but this does work...
This is fine, but the terminology here needs to be specific. For the clients this is an outgoing mail server. For Courier this is incoming mail.
There should NOT be an SPF issue in here, because Courier should not be doing SPF checks for mail from authenticated incoming sources. Your clients must authenticate themselves in order to use the server for outgoing mail, of course, and that should turn off the SPF checks.
So when you mention SPF here, that's when I do not follow you. There could only be one possible way SPF can relate here.
Irrespective of which IP address a message was received at, outgoing mail is independent of that. It will use whichever default IP address the kernel wants to use. So, in the land of SPF, all IP addresses your server can possibly use would need to be listed in SPF for any domain that you're sending mail for.
So that a client with, say, vdomain1.com as the outgoing mailserver can connect on port 465, get the right certificate for vdomain1.com, and the recipient end-user gets... Received: from vdomain1.com ([::ffff:xx.xx.xx.11]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by xxxxxx.org with ESMTPS; Sat, 14 Apr 2012 15:49:56 -0700 id 0000000000020522.000000004F89FF15.0000096A Received-SPF: pass (Address passes the Sender Policy Framework) SPF=HELO; sender=vdomain1.com; remoteip=::ffff:xx.xx.xx.11; remotehost=; helo=vdomain1.com; receiver=xxxxxx.org; Received-SPF: pass (Address passes the Sender Policy Framework) SPF=MAILFROM; sender=u...@vdomain1.com; remoteip=::ffff:xx.xx.xx.11; remotehost=; helo=vdomain1.com; receiver=xxxxxx.org;
No, this should not happen. Courier should not be doing an SPF check if this is your client, authenticated, with relaying privileges.
If this is your client, and it wants to use your server for the client's outgoing mail as a smarthost, you have to be authenticating this client.
I don't see authentication stuff in the Received: header here, so you have to be authenticating by IP address, with a RELAYCLIENT setting in smtpacces for that IP address, right?
> It would be possible to implement something like that – but at the > moment this does not exist. Any plans to do so in the future? I've got a test machine running courier-mta 0.67.0 with 3 domains on 3 IPs with their own certificates if that is of any use :-)
Well, I thought what you were talking about is using the same IP address for outgoing messages as the IP address they were received from, but the above suggests that you're really talking about something else. If you just need SPF to be reflect your outgoing mail's IP addresses, just set the SPF records to that, and that's it. SPF is not used when receiving mail from authenticated clients, so it won't impact incoming mail from those authenticated clients. You can set up the SSL certs whichever way you want, they have no impact.
That's the easy way out. Although I do see some benefit to using the same IP addresses for outgoing mail from the incoming mail; it's doable; it's always good to have a test environment available, but based on the above it doesn't look like what you're talking about, really.
Also note that, I don't know what Postfix does, but Courier does not close the outgoing connection immediately after sending a message. It'll hold it open for a while, and if another message to the same domain comes in, it'll use the existing connection. If the first message was from one IP address, but the second message is from a different IP address, it will be necessary to disconnect, and then reconnect. Just realized it, this morning, while thinking about it on my morning jog.
pgpr9eBUUVNtn.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
