[SOLVED] Cant send email, can receive them

[nvargas]

Hello,

I've been dealing with this since yesterday. My Zimbra server isn't allowing to send messages, but it receives them just fine.

Whenever I try to send a message, it asks for my password (Im using Auth Plain) and then it says that the server refused the connection.

My hosts file is

127.0.0.1       localhost.localdomain localhost
165.98.132.14 ni01.newcom.com.ni ni01

If I dig my domain I get

 dig -t mx newcom.com.ni

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.1 <<>> -t mx newcom.com.ni
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64544
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5

;; QUESTION SECTION:
;newcom.com.ni.                 IN      MX

;; ANSWER SECTION:
newcom.com.ni.          10800   IN      MX      0 mailproxy1.ni.amnetdatos.net.

;; AUTHORITY SECTION:
newcom.com.ni.          10800   IN      NS      dns1.ni.amnetdatos.net.
newcom.com.ni.          10800   IN      NS      dns2.ni.amnetdatos.net.
newcom.com.ni.          10800   IN      NS      dns3.ni.amnetdatos.net.
newcom.com.ni.          10800   IN      NS      ns.newcom.com.ni.

;; ADDITIONAL SECTION:
mailproxy1.ni.amnetdatos.net. 10800 IN  A       165.98.132.12
ns.newcom.com.ni.       10800   IN      A       200.30.128.111
dns1.ni.amnetdatos.net. 10800   IN      A       165.98.132.2
dns2.ni.amnetdatos.net. 10800   IN      A       165.98.134.2
dns3.ni.amnetdatos.net. 10800   IN      A       200.12.224.14

;; Query time: 0 msec
;; SERVER: 165.98.132.2#53(165.98.132.2)
;; WHEN: Fri Jun  4 04:15:18 2010
;; MSG SIZE  rcvd: 229

When I wget the SOAP address I get

wget http://ni01.newcom.com.ni:7071/service/admin/soap
--2010-06-04 04:42:24--  http://ni01.newcom.com.ni:7071/service/admin/soap
Resolving ni01.newcom.com.ni... 165.98.132.14
Connecting to ni01.newcom.com.ni|165.98.132.14|:7071... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2010-06-04 04:42:25--  (try: 2)  http://ni01.newcom.com.ni:7071/service/admin/soap
Connecting to ni01.newcom.com.ni|165.98.132.14|:7071... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2010-06-04 04:42:27--  (try: 3)  http://ni01.newcom.com.ni:7071/service/admin/soap
Connecting to ni01.newcom.com.ni|165.98.132.14|:7071... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2010-06-04 04:42:30--  (try: 4)  http://ni01.newcom.com.ni:7071/service/admin/soap
Connecting to ni01.newcom.com.ni|165.98.132.14|:7071... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

... and so on

Any help will be greatly appreciated.

[uxbod]

Is outbound email being sent through mailproxy1 ? Have you disabled DNS lookups within the Zimbra Admin GUI under the MTA tab ?

[nvargas]

Thank you for your prompt response.

Not that long after I posted my message, I found out that the problem was at saslauthd, the server protocol and port wasn't right, so I changed it.

Now the problem seems to be that response is very slow.

BTW, Mailproxy is just for inbound mail, acts as a spam/antivirus filter.

And no, I haven't disabled DNS checks.

[uxbod]

What do you mean by really slow ? Sending email ? or the general responsiveness of the system ?

[nvargas]

Both. Its a Quad Core Xeon with 4 GB RAM. It was down for 12 hours, so I guess all of the off time is taking its toll, but processing doesn't seem to be that high. The java process is above 1.5 GB, MySQL around 1 GB.

It takes about 15 seconds to send an email.

[nvargas]

Ok, I solved it.

After reading this post [SOLVED] SASL LOGIN authentication failed: authentication failure I checked my saslauthd.conf and saw it was on the wrong port. I modified it to the right port and also hardcoded the address on the saslauthd.conf.in.

When I restarted the saslauthd service, I was able to authenticate and send email again, but it was too slow. The culprit was the mail queue, it was over 1,500 messages, most of them on the deferred queue. I deleted all of the irrelevant ones, and moved the rest to the active queue. Problem solved.