I've had a hell of a time getting major email servers to accept our email without considering it spam...  Part of my problem seems to be with PTR/RDNS and SPF.  I have those records set up for the IP address I have bound SMTP to in Xeams, but after getting many messages about SPF lookup failures I started taking a closer look.

Despite having Xeams SMTP bound to a specific IP, the email servers on the other end are getting OTHER IP addresses assigned to the same machine.  In the mail header, there are TWO "Received" IP addresses listed, neither of which are the IP I have SMTP bound to!

In other words, say I have 3 IP addresses on the email server:  5.5.5.1, 5.5.5.2, 5.5.5.3

I have SMTP Bound to IP 5.5.5.2 in Xeams, but servers are listing emails as being received from 5.5.5.1 and 5.5.5.3

Is there any way to make all traffic and header information come from a SPECIFIC IP?  Or am I missing something?...  Confused and dazed...

Dear Danny,

The SMTP binding in only for in-bound, not out-bound. Use the following mechanism to force Xeams to use a specific IP for out-bound.

• Look for server.properties file in $INSTALLDIR\config folder. If you're on Windows, make sure the name is server.properties and NOT service.properties or server.properties.txt. Create a new file if server.properties is missing.
• Enter the following line towards the end:
  
  outbound.smtp.binding.ip=5.5.5.1
• Save and restart Xeams

Thank you, this solved the SPF problem.  I'm surprised that this is not more of a problem for machines with multiple IP addresses.   I'm even more surprised that a setting this important to SPF is not readily available to be set up properly.  I had to create the server.properties file.  

Where is there a list of all the setting that can be made in the server.properties file?  Perhaps there are more things hidden away that I should be changing but am not aware the setting exists...

Finally, that did correct the FIRST IP showing up in the email header, which is obviously the originating IP.  The second IP in the header still does not show the correct IP, but I'm not sure if that is going to be a problem:

x-sender: danny@zzz.com
x-receiver: test-b763405a@appmaildev.com
Received: from mail.zzz.com ([5.5.5.1]) by appmaildev.com with Microsoft SMTPSVC(8.5.9600.16384);
	 Wed, 25 Jan 2017 22:16:48 +0000
X-BYPSHEADER: 1729145
X-SMScore: -496
Message-ID: <1078688873.6.1485382609038.JavaMail.SYSTEM@ZZZ-WebServer>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_5_713421782.1485382609038"
X-LCID: 2275216
Received: from [(5.5.5.2)] by ZZZ-WebServer with Xeams SMTP; Wed, 25 Jan 2017 22:16:48 +0000 (GMT)
X-SM_EnvelopeFrom: danny@zzz.com
X-SM_RECEIVED_ON: Wed, 25 Jan 2017 22:16:48 +0000 (GMT)


As you can see above, the second "Received" IP does not match the first.  Again, I'm not sure this is going to be a problem, but thought I would pass the info along.

Danny,

We have found that most companies use NATing and therefore, the outside IP address is always the same regardless of what they use on their LAN. This is obviously not the case on your network.

The second IP address in the header should not matter. In fact, even the first one should not matter. I say that because the receiving email server does not look at the email header to determine the source - they look at the TCP/IP header. Email headers can be forged very easily but TCP/IP headers are not very easy to forge, particularly if the message is coming from the Internet.

Well, just so you know, there apparently are SPF checking systems out there using that first IP in the header.  Your setting stopped me from getting SPF rejections from @weg.com addresses at the very least, and if one major company is using SPF checking software that uses the header IP, I'd be willing to bet there are others..  

Also the appmaildev.com SPF test uses it (which is what led me on the search for how to change the originating IP):

But seriously, thank you for your response and help!

Danny,

If a system is checking the email headers, that is wrong and here is why.

• A Received header is always added by the receiving server. Consider the following example:
  • userA@xyz.com sends an email to friend@abc.com. This message goes to xyz.com's SMTP server. There are no received headers at this time in the email messages
  • The first received header is added by xyz.com's SMTP server containing userA's local IP address, which could be 192.168.1.x
  • When abc.com's SMTP server receives this message, there is ONLY ONE received header in the email, which is for 192.168.1.x. The second Received header will be added by abc.com's SMTP server and will most likely contain the IP address of xyz.com's SMTP server. This IP address is extracted from TCP/IP packet header not email header.
  • If xyz.com publishes their SPF record, there is no way the SMTP for abc.com can parse the header because it is not there yet.
• Therefore, an SPF lookup should never rely on RFC 822 headers.

"there apparently are SPF checking systems out there using that first IP in the header"

No. There aren't.

I have a Xeams server running on a dual-nic system and there were messages being logged in OutboundAuditTrailFailure.log indicating that the message was being rejected because of the IP being used.   The server has both a commercial and residential broadband connection and the commercial connection is the one the email server is configured to use.  

The commercial connection has an private IP or 192.168.0.2 and the residential connection has an IP address of 192.168.1.2

I have added the line outbound.smtp.binding.ip=192.168.0.2 to the \config\service.properties file (which I did not have to create) but email is still being rejected because it is being sent from the wrong IP address.

Any advice on what I can check, I would appreciate it.   Thank you.

I apologize for being careless - I misread the original email and thought the file to add outbound.smtp.binding.ip=192.168.0.2 to was service.properties.   I did not have a server.properties file but once I created it, restarted the server - I was able to send an outgoing message I was unable to earlier.

I will continue to monitor but I think (I hope) this has fixed the problem.

Thank you.