Postfix – Fix Temporary Authentication Failure 454 4.7.1 Relay Access Denied

iptablespostfixsmtpsquirrelmail

I can receive mail, but cannot send to outside world in Squirrelmail.

Message not sent. Server replied:

    Temporary authentication failure
    454 4.7.1 <email@somemail.com>: Relay access denied

I double checked that postfix works, i.e. able to telnet via mail.domain.com and smtp.domain.com. Dovecot works too. Seems that Squirrelmail is a suspect. Playing with configurations, not sure what could cause the problem.

Logs show this info:

mail.domain.com postfix/smtpd[4443]: connect from mail.domain.com[XXX.XXX.XXX.XXX]
mail.domain.com postfix/smtpd[4443]: NOQUEUE: reject: RCPT from mail.domain.com[XXX.XXX.XXX.XXX]: 454 4.7.1 <email@somemail.com>: Relay access denied; from=<user@domain.com> to=<email@somemail.com> proto=ESMTP helo=<mail.domain.com>
mail.domain.com postfix/smtpd[4443]: lost connection after RCPT from mail.domain.com[XXX.XXX.XXX.XXX]
mail.domain.com postfix/smtpd[4443]: disconnect from mail.domain.com[XXX.XXX.XXX.XXX] ehlo=1 mail=1 rcpt=0/1 commands=2/3

netstat -plntu

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:110             0.0.0.0:*               LISTEN      940/dovecot         
tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN      940/dovecot         
tcp        0      0 192.168.124.1:53        0.0.0.0:*               LISTEN      1107/dnsmasq        
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      1905/cupsd          
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      937/master          
tcp        0      0 0.0.0.0:993             0.0.0.0:*               LISTEN      940/dovecot         
tcp        0      0 0.0.0.0:995             0.0.0.0:*               LISTEN      940/dovecot         
tcp6       0      0 :::110                  :::*                    LISTEN      940/dovecot         
tcp6       0      0 :::143                  :::*                    LISTEN      940/dovecot         
tcp6       0      0 :::80                   :::*                    LISTEN      3521/httpd          
tcp6       0      0 ::1:631                 :::*                    LISTEN      1905/cupsd          
tcp6       0      0 :::993                  :::*                    LISTEN      940/dovecot         
tcp6       0      0 :::995                  :::*                    LISTEN      940/dovecot         
udp        0      0 127.0.0.1:323           0.0.0.0:*                           736/chronyd         
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           722/avahi-daemon: r 
udp        0      0 0.0.0.0:55024           0.0.0.0:*                           722/avahi-daemon: r 
udp        0      0 192.168.124.1:53        0.0.0.0:*                           1107/dnsmasq        
udp        0      0 0.0.0.0:67              0.0.0.0:*                           1107/dnsmasq        
udp6       0      0 :::41119                :::*                                722/avahi-daemon: r 
udp6       0      0 ::1:323                 :::*                                736/chronyd         
udp6       0      0 :::5353                 :::*                                722/avahi-daemon: r

Iptables are as follows:

iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A FORWARD -d 192.168.124.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.124.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT

iptables -L

    Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             192.168.124.0/24     ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.124.0/24     anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootpc

iptables-save

*mangle
:PREROUTING ACCEPT [9985:4365661]
:INPUT ACCEPT [9969:4364853]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [10509:2272775]
:POSTROUTING ACCEPT [10545:2275457]
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
*nat
:PREROUTING ACCEPT [78:6056]
:INPUT ACCEPT [62:5248]
:OUTPUT ACCEPT [1057:68220]
:POSTROUTING ACCEPT [1057:68220]
-A POSTROUTING -s 192.168.124.0/24 -d 224.0.0.0/24 -j RETURN
-A POSTROUTING -s 192.168.124.0/24 -d 255.255.255.255/32 -j RETURN
-A POSTROUTING -s 192.168.124.0/24 ! -d 192.168.124.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.124.0/24 ! -d 192.168.124.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.124.0/24 ! -d 192.168.124.0/24 -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [9969:4364853]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [10509:2272775]
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A FORWARD -d 192.168.124.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.124.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
COMMIT

Update 15.11.2017:
This issue has been overcome by changing config in Squirrelmail.
Run

/usr/share/squirrelmail/config/conf.pl

Go to: Server Settings -> Update IMAP Settings -> imap.domain.com
and Update SMTP Settings -> smtp.domain.com.
It used to be just localhost.

Update 14.11.2017:
Disabled firewall and was able to send mail again. However, problem with iptables remain. Also in SELinux I tried:

setsebool -P httpd_can_network_connect 1

Update 13.11.2017
Cannot send an email on Squirrelmail after enabling firewall and opening ports 80/443, 25/143. Please, help!

ERROR:
Message not sent. Server replied:

Connection refused
111 Can't open SMTP stream.

This question comes from the following thread.
Postfix, dovecot, squirrelmail server able to send but not receive emails

Best Answer

I was able to send email finally by editing the Squirrelamil config file. Basically I switched from SMTP to Sendmail. In /etc/squirrelmail/config.php change

$useSendmail            = true;

then restart apache

systemctl restart httpd

then allow Selinux to use sendmail

setsebool -P httpd_can_sendmail=1

I doubt that this configuration of Squirrelmail will hold long. Im definitely going to play with it. For now, not sure why SMTP didn't work, but sendmail did. Hopefully, will figure out by messing with SELinux. In the meantime, anyone has opinion on whether SMTP or Sendmail is the best one to use?

Related Solutions

Linux – iptables port forward forwarding

You're sending the traffic to 10.52.208.221. Given the config you posted, your problem is the webserver, not the firewall. Your rules look to be correct. FORWARD and INPUT are redirected to RH-Firewall-1-INPUT where your first rule is to allow all traffic. As somebody else pointed out, you could be allowing all traffic on eth1, while the world is actually coming in eth0. Secondary, you have to NAT the traffic as it goes back out to the world

iptables --table nat --append POSTROUTING --proto tcp --dport 80 --jump MASQUERADE -o OUT_INTERFACE

Your traffic originating from the router will never hit the input or forward chains, but instead traverse the output chain on to the webserver. Other systems in that subnet will similarly go directly to the webserver. Systems out on the world at large however will traverse the INPUT / FORWARD chains and need SNAT as well as DNAT so that it appears to the world to be one machine. You still cannot test from within your network. you must test from the opposite interface from the webserver. Get me your IP addresses and I'll point you to the proper configs.

Iptables – ftp tls firewalled :(

In Passive mode, when the client wants to get a file from the server or send a file to the server, the FTP server will pick a random port and send that port to the FTP client.

When you're not using encryption, a properly configured firewall (using the ip_conntrack_ftp helper kernel module, which may be what you're missing for non-TLS connections) would "listen in" on the connection and mark these connections as RELATED. With encryption the firewall can't listen in.

The quick and dirty solution to this is to configure the FTP server to choose a small range of ports for passive connections, and then allow access to all of these ports. For instance, in vsftpd:

pasv_min_port=12000
pasv_max_port=12049

Then in iptables:

iptables -A INPUT -p tcp -m tcp -i eth0 --dport 12000:12049 -j ACCEPT

Allowing anyone to access these ports opens one possible exploit: if someone were to be scanning them over and over they might get lucky and be able to "beat" the real user to the data port and grab the file. Ideally your FTP server would check and make sure the connection is coming from the same place as the original connection, but thanks to things like "FXP" (transferring files from one server to another server by convincing one to make an active connection to the other's passive data port) some servers don't check the connection by default. You should check your configuration file and see if there is an option to disable FXP, and use it. (vsftpd calls this "promiscuous" and is disabled by default.)

Best Answer

Related Solutions

Linux – iptables port forward forwarding

Iptables – ftp tls firewalled :(

Related Topic