On 20/04/12 09:20, Sam Varshavchik wrote: >> 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 > > 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.
No SPF issue on the originating mailserver where the clients MUA connects to port 465 of, say, vdomain1.com which resolves to xx.xx.xx.11 and they get the right certificate of esmtpd.pem.xx.xx.xx.11. FWIW there is only a single IP for each SPF/TXT record per domain... vdomain0.com = "v=spf1 ip4:xx.xx.xx.10 -all" vdomain1.com = "v=spf1 ip4:xx.xx.xx.11 -all" vdomain2.com = "v=spf1 ip4:xx.xx.xx.12 -all" > 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. Sorry for me not being clear. Nothing to do with SPF on this particular server, the only point where SPF comes into it is on the destination recipients mailserver where the headers of messages reflect each of the vdomains used in the originating mailserver that the sending client set as outgoing mailserver. > 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. This is where my postfix example "works its magic" as it seems it really does dynamically bind outgoing traffic to the same specified eth0:* virtual interface that was used for the incoming ESMTP connection. > 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. There could be up to 100s of these vdomains on a single server. Add or remove an IP or vdomain and the TXT record has to be twiddled accordingly with associated propagation delays. >> 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... primarydomain.com is the canonical domainname associated with the eth0 interface set to xx.xx.xx.1 on the originating mailserver, xxxxxx.org is the destination mailserver. >> 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. The above example was from the message recipients final destination mailserver. > 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, Yes, that's it. And to be really nice, postfix throws in a virtual hostname as well (during the SMTP exchange to the recipient server) that ends up being used in -> Received: from vdomain1.com (rather than primarydomain.com). > 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. Appreciate the fact that you are considering this. I tried to keep my posts short but I should have provided a clear example of the whole procedure in the first place. The basic scheme is that the originating mailserver can provide for any number of vdomains, that when used by an authenticating MUA on port 465, then onsend the message to the target mailserver from the same IP as it arrived on. If the SMTP exchange can include the vdomain as originating mailserver hostname then that should be enough to provide a set of headers that can pass both SPF and "eyeball" checks that it came from the vdomain rather than the primary domain. I guess my Subject line should have been "Multiple SSL certs AND multiple IPs" ------------------------------------------------------------------------------ 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
