SMTP used as Open Relay| proper MTA trusted network Config.

[Johnny19]

our Zimbra instillation has been abused as an open relay and I am attempting to Configure SMTP Auth but It appears other parts of the configuration are askew. the current MTA trusted networks are

127.0.0.0/8,192.168.111.0/24

but they were

127.0.0.0/8,192.168.111.0/24,0.0.0.0/0

Allowing all networks, The .111 is the local LANI additionally need to be able to accept mail from branch offices on subnets other than .111; which I assume would be covered if I just trusted 192.168.0.0/16. More troubling than all that is with the current set up

127.0.0.0/8,192.168.111.0/24

with no SMTP Auth on, sending mail from inside the lan to localhosts such as

user@mydomain.com to otheruser@mydomain.com results in an error.

504:<computername> Helo command rejected: need fully-qualified hostname

but the zimbra install does have a FQDN

zmlocalconfig | grep host
ldap_host = myhost.mydomain.com
logger_mysql_bind_address = localhost
mysql_bind_address = localhost
snmp_trap_host = mydomain.com
zimbra_server_hostname = myhost.mydomain.com
zimbra_zmprov_default_soap_server = localhost


cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
192.168.111.177 myhost.mydomain.com myhost

any help at this point would be greatly appreciated.

[jrefl5]

I would suggest that you enter only those systems that actually send mail via the zimbra server.
The web interface, ZD, etc will send as localhost for those that login via those clients.
Using 192.168.111.0/24 allows your router, or anything sending through it access.

[Johnny19]

Originally Posted by jrefl5

I would suggest that you enter only those systems that actually send mail via the zimbra server.
The web interface, ZD, etc will send as localhost for those that login via those clients.
Using 192.168.111.0/24 allows your router, or anything sending through it access.

Somehow it's just not configured correctly and without the 0.0.0.0/0 network in there it won't work and all mail I attempt to send through even to recipients inside the domain. I receive an error. so dispite my local machine being 192.168.111.80 and the zimbra server is 192.168.111.177 this MTA still responds with an error.

504 <CorpIT01>: Helo command rejected: need fully-qualified hostname

this happens either when I remove the 0.0.0.0/0 MTA or when I enable SMTP/Auth (and I need SMTP auth to work to stop from being used as a relay)

[Johnny19]

I have a great need for this to be put to bed. any suggestions or input from the Zimbra experts or Mail Transport pro's out there would be greatly appreciated.

If there is more information you need let me know.

[phoenix]

Originally Posted by Johnny19

our Zimbra instillation has been abused as an open relay and I am attempting to Configure SMTP Auth but It appears other parts of the configuration are askew. the current MTA trusted networks are

127.0.0.0/8,192.168.111.0/24

This is the correct setting.

Originally Posted by Johnny19

but they were

127.0.0.0/8,192.168.111.0/24,0.0.0.0/0

Allowing all networks,

As you have seen, this is the incorrect setting and the soruce of the relay problem.

Originally Posted by Johnny19

The .111 is the local LANI additionally need to be able to accept mail from branch offices on subnets other than .111; which I assume would be covered if I just trusted 192.168.0.0/16.

Why do you need other subnets in there, how do your remote branch office users connect to your Zimbra server is it via a LAN or over the internet?

Originally Posted by Johnny19

More troubling than all that is with the current set up

127.0.0.0/8,192.168.111.0/24

with no SMTP Auth on, sending mail from inside the lan to localhosts such as

user@mydomain.com to otheruser@mydomain.com results in an error.

504:<computername> Helo command rejected: need fully-qualified hostname

Your LAN users should be using port 587 as the correct Submission port and not port 25, port 587 requires authentication and will allow users to send mail via the server.

Originally Posted by Johnny19

but the zimbra install does have a FQDN

That's fine but the problem isn't wioth the server it's a Protocol Check (in the Admin UI - Global Settings/MTA tab) that's stopping your users from sending mail.

[Johnny19]

Originally Posted by phoenix

This is the correct setting.

Why do you need other subnets in there, how do your remote branch office users connect to your Zimbra server is it via a LAN or over the internet?
.

I guess this is an assumption on my part, I'm not clear on how the packets look to zimbra, All of our branch offices are connected to the Corp Office via a MPLS network. when smtp packets come from outside the .111.x network I assumed they would have their own identifying IP data and not lets say the IP of our corp router. and that the Zimbra smtp MTA would see they were from another Class C Internal sub net.

Originally Posted by phoenix

This is the correct setting.
Your LAN users should be using port 587 as the correct Submission port and not port 25, port 587 requires authentication and will allow users to send mail via the server.

Awesome! I will look into this Immediately.
I will respond as soon as I have addressed your other suggestions. Thanks!!!

[Johnny19]

It appears the reason for the 0.0.0.0/0 networks is so road warriors can connect via clients, such as outlook, and entourage. In all likelihood we will need to make a policy change and force these users to use the Web Portal. In the mean time I want to review the changes I have made and the results.

first is the SMTP Auth, which we could not enable right away because port 587 is being blocked on our boarder routers, by our ISP we will have to wait until they open this port. We should be able to test this later in the week.

second is the MTA networks we are currently using. I have set them up as so.

127.0.0.0/8,192.168.111.0/24,xxx.xxx.xxx.0/24

(where xxx represents the boarder routers range)
this results in log files that indicate they prevent hosts not in the FQDN
for example.
Aug 24 09:57:44 sysmax postfix/smtpd[10152]: NOQUEUE: reject: RCPT from unknown[114.243.164.252]: 504 <bwzitj>: Helo command rejected: need fully-qualified hostname; from=<ggqkhke@mydomain.com> to=<wrf_99999@yahuo.com.cn> proto=SMTP helo=<bwzitj>

however All of our mail seems to queue up reporting their connection to the SMTP server is timing out. with errors in the zimbra admin utilitie as such.

Aug 24 10:11:39 hostname postfix/qmgr[8005]: 4BDC75FD81CC: to=<user@mydomain.com>, relay=none, delay=103, status=deferred (delivery temporarily suspended: connect to hostname.mydomain.com[xxx.xxx.xxx.13]: Connection timed out)

In addition to dozens of these errors in the log per minute


Aug 24 10:48:29 hostname postfix/smtpd[10449]: lost connection after CONNECT from unknown[xxx.xxx.xxx.9]
Aug 24 10:48:29 hostname postfix/smtpd[10449]: disconnect from unknown[xxx.xxx.xxx.9]
Aug 24 10:48:29 hostname postfix/smtpd[10449]: warning: xxx.xxx.xxx.9: hostname mail2.mydomain.com verification failed: Name or service not known
Aug 24 10:48:29 hostname postfix/smtpd[10449]: connect from unknown[xxx.xxx.xxx.9]
Aug 24 10:48:29 hostname postfix/smtpd[10449]: lost connection after CONNECT from unknown[xxx.xxx.xxx.9]
Aug 24 10:48:29 hostname postfix/smtpd[10449]: disconnect from unknown[xxx.xxx.xxx.9]
Aug 24 10:48:29 hostname postfix/smtpd[10449]: warning: xxx.xxx.xxx.9: hostname mail2.mydomain.com verification failed: Name or service not known
Aug 24 10:48:29 hostname postfix/smtpd[10449]: connect from unknown[xxx.xxx.xxx.9]
Aug 24 10:48:29 hostname postfix/smtpd[10449]: lost connection after CONNECT from unknown[xxx.xxx.xxx.9]
Aug 24 10:48:29 hostname postfix/smtpd[10449]: disconnect from unknown[xxx.xxx.xxx.9]
Aug 24 10:48:29 hostname postfix/smtpd[10449]: warning: xxx.xxx.xxx.9: hostname mail2.mydomain.com verification failed: Name or service not known


this Ip range listed above as xxx is in my MTA/Trusted.
Am I on the right track. or totally off base.

[phoenix]

Originally Posted by Johnny19

It appears the reason for the 0.0.0.0/0 networks is so road warriors can connect via clients, such as outlook, and entourage. In all likelihood we will need to make a policy change and force these users to use the Web Portal.

I'd suggest that should be an immediate policy change, with 0.0.0.0/0 in the Trusted Network you've opened your server to the whole of the internet. Make 'Road Warriors' use port 587 for connecting to the server for mail submission (when your ISP fixes their routers ).

Originally Posted by Johnny19

second is the MTA networks we are currently using. I have set them up as so.

127.0.0.0/8,192.168.111.0/24,xxx.xxx.xxx.0/24

(where xxx represents the boarder routers range)
this results in log files that indicate they prevent hosts not in the FQDN
for example.

You really shouldn't need this in your Trusted Networks, your ISPs routers should never need to be in that setting. How, and why, did you determine they were necessary?

Originally Posted by Johnny19

this Ip range listed above as xxx is in my MTA/Trusted.
Am I on the right track. or totally off base.

Do you have any firewall or NAT router in front of your Zimbra server (I assume you do as you have a private LAN IP)? Which make of NAT router are you using (CICSO, by any chance)? As I mentioned earlier, you shouldn't need any of your ISPs routers in the Trusted Networks.

[Johnny19]

Originally Posted by phoenix

You really shouldn't need this in your Trusted Networks, your ISPs routers should never need to be in that setting. How, and why, did you determine they were necessary?

I have only made that determination via trial and error; If I remove the boarder router from the Trusted/MTA my users receive the FQDN error when attempting to send mail through a client.

such as
504 <mycomputer>: Helo command rejected: need fully-qualified hostname

as I have said there is no Domain structure in our current network setup and since we have over 24 branch offices, implementing one would be an enormous project in itself.

[phoenix]

Originally Posted by Johnny19

504 <mycomputer>: Helo command rejected: need fully-qualified hostname

That doesn't make sense and I can't understand why that would happen. What sort of 'routers' are these, do you know? Is your ISP using any sort of firewall or port blocking? Have you also spoken to your ISP about this problem?