Unable to send mail

[carnold]

Well, this use to work without any problems but since an upgrade, no one can send email. Using (now) 5.0.10 OSS on SLES10 SP1. Use to run 5.0.9 and we upgraded because of the java error from the admin panel. We also hoped that this upgrade would take care of this problem but it has not. I have added the networks to MTA via the admin panel, 127.0.0.1/32 192.168.1.0/24 152.16.0.0/16. Still no one from 152.16 can send email, they can receive email but not send. I telnet (from 192.168) to the mail server on 25 and am able to send an email. I am not able to telnet from 152.16 as the firewall is under someone elses control. I looked in the /opt/zimbra/log/mailbox.log file and do not see any error related to this. Am i looking in the right place for this error or should it be somewhere else? I would appreciate any help.

/EDIT- We can send from the web interface fine. /EDIT
/EDIT - Again - I searched through messages and mailbox.log and do not even see a SMTP entry. There are 0 postfix entries in the log and the only smtp entries are from the web client. In need of help, please. /EDIT

[carnold]

I can send email using our zimbra server from my iphone. Still can not send email from 152.16. 152.16 does not block port 25. Also found out no email is being sent from 71.x.x.x address either.

[dwmtractor]

I think the answer lies in this statement you made:

I am not able to telnet from 152.16 as the firewall is under someone elses control.

Sending mail depends on SMTP which is a separate connection from your IMAP or POP (You did not say which you were using). If the firewall is blocking port 25, of course you won't find messages in your Zimbra log because the requests never get there. I don't understand why this ever would have worked on previous versions as the ports are not controlled by Zimbra.

You might try (many of us have found it works better anyway) enabling secure login for your SMTP--using SSL/TLS and denying clear-text login is more secure and less hackable/spammable/spoofable anyhow.

[carnold]

I doubt that is the answer as this worked before and port 25 is not blocked at the firewall. Using imap connections and the reason i did not say what type of connection is because, as i posted earlier, they can get email, just can not send, which is port 25 and i don't believe it has anything to do with imap.

[dwmtractor]

Originally Posted by carnold

I doubt that is the answer as this worked before and port 25 is not blocked at the firewall. Using imap connections and the reason i did not say what type of connection is because, as i posted earlier, they can get email, just can not send, which is port 25 and i don't believe it has anything to do with imap.

You're right, it doesn't. But as I'm sure you know, your mail transport is only going to accept incoming SMTP (unauthenticated) for your internal users not for everybody. . .you already know that the alternative would be an open relay.

So several questions:

1. Are you still getting mail from outside? If so, then clearly your SMTP engine is working, 'cause that's what relays ALL incoming mail.
2. Assuming a "yes" answer to (1), I would guess that perhaps your upgrade turned off the ability to do clear text login or authentication for your users in order to accept them as authorized relays, but this assumes that your SMTP traffic is getting there from the 152.16.x.x subnet--and from what you have said so far this fact is by no means established. Nevertheless I'd go back and check my settings for the MTA to be sure they haven't changed from prior installations. . .
3. But more importantly, just where is this 152.16 subnet? Is it on a different network entirely? Maybe even outside? A DMZ on your own network? etc. etc.? Since you said you can't telnet /25 from that subnet, what routing issues, other firewalls, port translation, or whatever could be in the way?

Note in reference to point 3 that the issue COULD have to do, not with the traffic FROM 152.16.x.x TO your server, but on the return hop. Depending on how you route your traffic to your mailserver, if it's coming in on one network adaptor and leaving by another, all sorts of authentication can get screwed up. This post discusses this potential problem in greater detail. . .

[carnold]

Originally Posted by dwmtractor

So several questions:

1. Are you still getting mail from outside?

1. Yes
   

   Assuming a "yes" answer to (1), I would guess that perhaps your upgrade turned off the ability to do clear text login or authentication for your users in order to accept them as authorized relays,

   I have TLS enable and for kicks i enabled clear text, still not able to send email
   

   but this assumes that your SMTP traffic is getting there from the 152.16.x.x subnet--and from what you have said so far this fact is by no means established. Nevertheless I'd go back and check my settings for the MTA to be sure they haven't changed from prior installations. . .

   Huh? The 152 address is a remote office that connects to the zimbra server via imap and sends through the same zimbra server
   

   But more importantly, just where is this 152.16 subnet? Is it on a different network entirely? Maybe even outside?

   Yes to all those. It is entorely a different network outside of the zimbra server
   [QUOTE]A DMZ on your own network? etc. etc.?[?QUOTE]
   See above
   

   Since you said you can't telnet /25 from that subnet, what routing issues, other firewalls, port translation, or whatever could be in the way?

It is a small setup. 1 zimbra server with 10 users. 5 of those users connect from outside the zimbra server network (152). 1 router/firewall that has been in place for many years and zimbra has worked in the setup for about 6 months.

Note in reference to point 3 that the issue COULD have to do, not with the traffic FROM 152.16.x.x TO your server, but on the return hop. Depending on how you route your traffic to your mailserver, if it's coming in on one network adaptor and leaving by another, all sorts of authentication can get screwed up. This post discusses this potential problem in greater detail. . .

The setup is not that complicated. The 1 router/firewall forwards requests to an internal ip