Problems and solutions
|Previous Top Next|
While trying to send out mail the server replies "We don't relay". What does it mean?
The default settings require the SMTP-authentication is always performed when the mail is sent to external e-mail addresses. This way the server is protected against being used as the means of sending unsolicited e-mail (junk messages).
To eliminate that error message it is necessary to enable SMTP-authentication for the outgoing mail in the e-mail client's settings.
When launching the server the following error messages are written into the Error.log files: "! 15 Oct 2007 15:57:06 POP addresses configuration error" or "! 15 Oct 2007 15:57:06 SMTP addresses configuration error". What's wrong in the settings?
These error messages mean there is a conflict between the domains in the protocol settings. Most likely, for the given protocol, in one domain an IP-address was set for a certain subnet, while in the other domain this field has been left blank. The connections on that port are accepted either from the defined subnet or from all subnets, but not from both simultaneously. That is the reason of the conflict.
The "IP address" field might have been filled in by mistake. In most cases all connections should be accepted and that field has to be blank.
When launching the server the following error messages are written into the Error.log files: "Could not bind to address "0.0.0.0", port 25".
This means that port 25 (SMTP) is already used by another programme, mail server or the system's SMTP service is started.
To find out what occupied the port, run the following command from the command line:
telnet localhost 25
Usually, in the server's greeting its own name is mentioned.
When launching the server the following error messages are written into the Error.log files: "Could not bind to address "192.168.101.1", port 25".
Probably in the domain protocol settings the "IP address" field had been filled in by mistake or this address does not belong to that computer. In order to find out the IP-addresses of that computer it is necessary to run the following command from the command line:
To get all the information on the network settings run the following command:
While trying to send out mail the server replies "5.7.1 - unable to relay".
Obviously, this error message does not come from BatPost. While sending the mail out either there was another server in use by mistake or besides BatPost there was another server in play, which did intercept the SMTP port.
To clarify that it is necessary to run the following command on the server:
telnet localhost 25
and make sure the server's greeting contains this word: "BatPost".
The mail delivery (even local) takes too much time.
High CPU load.
Antivirus monitors may try scanning every incoming message. With a high amount of messages this might significantly slow down the server. Try disabling the antivirus and, if this solves the problem, it means the antivirus is unable to process such number of e-mails.
In order to find out which application loads the CPU you can make use of the Task Manager. In some cases it indicates that the CPU load is due to the System process. To get a more detailed information use the Process Explorer. You can download it from here:
While trying to receive mail the server replies "Authentication failed. Mailbox locked".
The POP3 protocol requires that the mail account is blocked while it is in use. If you try to access that account while someone has already established a connection with it, you will get the above mentioned error message.
You have to make sure that at a certain point of time a POP3 account is accessed only from one client. For instance, it is of no wonder when a user access his/hers e-mail account from work and from home, but does not do that simultaneously. On the other side there is IMAP, which allows multiple concurrent connections.
The server is unable to send mail to the external servers. What might be the problem?
First of all it is necessary to look through the Post.LOG file, it may contain error messages which could clarify the situation. If the DNS is used to deliver mail to external addresses it is necessary to make sure that its address is set accordingly and that it is functioning properly. In case you use a relay server you have to make sure the message has been successfully passed over to it.
Quite often while using DNS you may successfully connect to an external server, but it refuses to accept mail. The reason for that might go down to the extended check-ups of e-mail performed by the external server, which tries to combat spam this way. And so, the following might be checked:
|·||Whether our server is registered in the DNS (this implies we use a static IP-address).|
|·||Whether the PTR record is registered in the DNS reverse zone. This is characteristic to the mail.ru server, in case there is no PTR record, it returns the "550 Unroutable address" error message.|
Sometimes, the only solution to the problem is to use a relay server to send messages to external addresses.
We do not receive mail from outer world. What might be the problem?
There are two ways for the mail from external servers to arrive at our server:
|·||If we have our own mail domain and in the DNS it is prescribed that our server is responsible for mail in that domain, then other servers will contact us and hand over the mail. In this case the A record describing our IP-address and the MX record referring to the A record, have to be set for our server.|
|·||We can connect to the other servers and collect the
corresponding mail ourselves. In this case we can even lack our own
domain and fetch mail from certain addresses via "Remote POP".
In case we do have a mail domain, it can point to a server that temporarily collects mail for our domain (e.g. ISP's server). This intermediate server can store e-mails in its message queue and give them away via ETRN/ATRN or pile up messages into a special account so that we can fetch them via "Remote POP". The first instance is preferable as in this case the information on the initial message recipient is not lost, but not all servers support that. Anyway, the decision is up to the intermediate server owner.
Authentication fails. In the logs I see "Incorrect password", though I am sure the password is correct. What is the problem?
Most likely, in the e-mail client settings you entered only the user name without indicating the domain, while on the server such user exists in several domains. In this case the server will look for the user in all domains and will check the first one it finds possessing that name. To avoid such ambiguous situations you have to enter the whole username (coinciding with the e-mail address). In other words, instead of mere "user" put "email@example.com".
Authentication fails. In the logs I see"User not found", though such user exists. What is the problem?
There are two main reasons:
|·||A new domain with users had been created, but the server has not been restarted. Creating, deleting and changing the domain settings require the server to be restarted.|
|·||In the domain, to which the user belongs, the needed protocol is disabled. Or this protocol has been incorrectly set up. You have to make sure that in the domain settings on the "Protocols" tab the needed protocol is enabled and that in the Error.log file there are no messages regarding errors with that protocol. After altering the settings it is mandatory to restart the server.|
Changing settings does not take effect. In the Configurator the changes are visible, but the server functions as before. What do I have to do?
Changing some settings requires the server to be restarted in order for the changes to take effect. This refers to the domain settings, schedules, antivirus and anti-spam as well as to the settings under the "Options" section.