user46688's questions

I have a database server connected to an application server. The database server contains SQL code that generates automated emails to customers. The database server code creates the email then logs into the application server using the login credentials of one of the users to send the email.

One of my customers is not receiving such emails. Actually, their server receives the email, but rejects it as spam.

I think the reason for this is the Received-SPF external ip address xxx.xxx.xxx.xxx for the application server is different than the Received: ip address, which is the local IP for the database server. The auto-reply sent back from my customer ([email protected] below) server states

Diagnostic-Code: smtp; 5.3.0 - Other mail system problem 550-'5.7.1 Client does not have permissions to send as this sender' (delivery attempts: 0)

and includes the following header information:

Received-SPF: Pass (mail.customercompany.com: domain of
  [email protected] designates xxx.xxx.xxx.xxx as permitted
  sender) identity=mailfrom; client-ip=xxx.xxx.xxx.xxx;
  receiver=mail.customercompany.com;
  envelope-from="[email protected]";
  x-sender="[email protected]"; x-conformance=spf_only;
  x-record-type="v=spf1"
...
Received: from host3.mycompany.com ([xxx.xxx.xxx.xxx])
  by mail.customercompany.com with ESMTP...SHA384; 02 May 2017 15:40:41 -0400
Received: from [192.168.0.1] (port=17111 helo=mail.mycompany.com)
  by host3.mycompany.com with esmtpa (Exim 4.89)
  (envelope-from <[email protected]>)
  id 1d5df6-00023Y-SB
  for [email protected]; Tue, 02 May 2017 12:40:40 -0700
...
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host3.mycompany.com
X-AntiAbuse: Original Domain - customercompany.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - mycompany.com
X-Get-Message-Sender-Via: host3.mycompany.com: authenticated_id: [email protected]
X-Authenticated-Sender: host3.mycompany.com: [email protected]

Is it acceptable to include a private (internal) IP address in a SPF record, along with external IP address? Any downside?

Does this look like it might resolve this issue?

Any way to get the email header to report the application server IP address xxx.xxx.xxx.xxx instead of the db server internal ip [192.168.0.1] appearing in the Received: line (without porting the code to the application server)?

I don't want the outside world to see the external IP of the database server.

I have a database CentOS 7 server connected to an application CentOS 7 server via a cross connect cable. The mail server resides in the application server, with the following SPF configuration:

v=spf1 +a +mx +ip4:aaa.aaa.aaa.aaa +ip4:bbb.bbb.bbb.bbb ~all

where aaa.aaa.aaa.aaa and bbb.bbb.bbb.bbb are the external IP addresses for each server.

If the database server wants to send email via the application server using the local IP address (192.168.0.5), how can I configure SPF to either pass all local IP addresses (no checking done), or otherwise allow the local IP of 192.168.0.5 to pass SPF authentication?

Is the above configuration sufficient (e.g. based on external IPs), or do I need to do something additional to account for the internal IP address?

UPDATE

I'm using exim for email. To send email from the database server, it authenticates to SMTP as a user on the application server, and sends commands such as ehlo.

I've set Apache 2.4 server to AddDefaultCharset utf-8 in httpd.conf and my .htaccess file redirects all non-www and http to https://www.example.com

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [OR]
RewriteCond %{HTTPS} !on
RewriteRule ^(.*)$ https//www.example.com/$1 [R=301,L,NE]

If I look at HTTP response header, only traffic sent to https://www.example.com generates a UTF-8 response. The non-www and http traffic respond with ISO-8859-1 charset.

Anyone know how to ensure all URL-redirect HTTP responses are in UTF-8?

I modify my /etc/hosts.allow file as

sshd : 192.168.0.0/255.255.255.0 : allow
sshd : xxx.xxx.xxx.* : allow
sshd : ALL : deny

(where the xxx represent my actual IP address numbers and the wildcard * represents the full range 0-255) then restart sshd and Apache web server. I watch over the following week as IP addresses from foreign countries continue to appear in /etc/csf/csf.deny.

116.31.116.15 # lfd: (sshd) Failed SSH login from 116.31.116.15 (CN/China/-): 5 in the last 300 secs ...

Is my expectation correct that denied IP addresses in the hosts.allow file should not even be presented with a login screen to attempt to login, and thus the entries in the csf.deny log prove my hosts.allow file isn't doing what I want?

Or, am I being misled by the generic error message (5 in the last 300 secs) because in reality those IP addresses have not actually attempted to enter a user and password 5 times?

My goal is prevent non-approved IP addresses from being able to even enter a username and password. How can I tell that I'm achieving this or not?

What should I expect the csf.deny file to show when their IP is in fact denied?