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=user@vdom...;
>   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.