I've been running a CentOS/Dovecot/Postfix box as an email server for a while with no complications.

A few weeks ago users stopped being able to send emails through external clients. They can read an access their emails from Outlook/Evolution/Thunderbird clients but they cannot send any email messages.

The error message is very ambiguous to me. It basically says that the client cannot connect to the server.

I haven't changed any configuration files and the maillog is not recording these failed attempts.

I am a rookie at doing this kind of work and I am stumped.

Any help at pointing out any possible causes or any logs that I am missing or any resources that I could study would be greatly appreciated.

Edit: I can send emails through a local web based email client like roundcube or squirrel.


As Matt Simmons suggested I tried telneting the server. I was able to connect from the inside but not from the outside. I then decided to change the port and was able to connect from the outside and send emails from email accounts in my domain from outside clients.

However, now I cannot receive emails from accounts that live outside my server. Please help. I fixed small problem and created a big one.


I found out that my ISP is blocking the port 25. I am using the submission port instead.

Trying to connect with telnet from the outside and the inside as Matt Simmons suggested pointed me in the right direction and I got the final hint in the following thread:

My ISP is blocking port 25. Is port 587 a good replacement?



I don't use Centos, but I do use RHEL. One thing that soemtimes bites me with RHEL that I often forget to check is SELinux.

Try turning it off, i.e. setenforce 0 and see if that makes a difference. Sometimes people turn it off while they are doing set up and then forget to make the change permanent in the config file, then on reboot it comes back and things stop working,

  • Already tried it. Running sestatus tells me that it is disabled. – user6271 May 30 '09 at 16:19

Step 1 - Is the service running?

 service dovecot status

If no, then

 service dovecot start

Step 2 - Can you telnet to localhost on port 25 and 443?

If not, try restarting the service and and check again. If you still can't, check maillog and messages for useful output. You may have to run the server in debugging mode (which I don't know how to do, but you should be able to figure out by reading /etc/init.d/dovecot)

Step 3 - Can you telnet to the server on those ports from other machines?

If not, check the firewall on that machine. Check /etc/hosts.deny. Check for firewalls on the machines you're trying to connect to.

If you've successfully gotten this far and everything works, but your clients still can't connect, it's time to try being a client. Telnet to port 25 on the server (from another machine) and pretend to be an smtp client:

   HELO fakeclient
   MAIL FROM myemail@address.com
   RCPT TO: someone@theserver.com
   To: someone@theserver.com
   From: myemail.com
   Subject: Test 1

   This is test 1


Hopefully some diagnostic message will appear and let you know why it wasn't accepted for delivery. If it WAS accepted for delivery, pretend to be an IMAP server

Telnet to port 443 on the machine, and do this:

   ? LOGIN username password
   ? LIST "" "*"

If you successfully got that far, it's the mail clients that are broke. Check for broken proxy configurations, or worst case, reinstall.

  • I tried your telneting approach. I could connect from the inside but not from the outside. I changed the port to see what happened and I was able to conennect from the inside and outside, but now I can't receive email from another domains. I suck so much at this. – user6271 May 30 '09 at 17:24

The problem with using the submission port is that it is usually intended for use only by authenticated users. Because of this, external mail servers are not going to attempt to deliver mail to your server using the submission port.

  • That's fine - external mail servers should not have their outgoing mail ports blocked. Port 25 is intended to be used for MTA to MTA communication, whereas port 587 is intended to be used for MUA to MTA communication. – MikeyB Jun 4 '09 at 1:57
  • Right, but unless I'm misunderstanding the request, adolfojp's ISP has completely firewalled off port 25, so the MTA can't accept incoming connections from other MTAs. I think he's asking for a way around this. – Josh Steadmon Jun 4 '09 at 21:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.