There are two most probable reasons you may be having trouble with your outgoing mail.
The most likely is that you are attempting to use "mail.mydomain.com" as your outgoing SMTP server. While we do make an SMTP server at your domain name available, we strongly advise using the SMTP server that your local ISP provides you instead, while using mail.mydomain.com as your incoming (POP) server.
The reason for this is that many ISPs have begun blocking access to SMTP servers off of their networks; sending through off-network SMTP servers is a technique often used by spammers and viruses, and by blocking this they help make the Internet safer for everyone. If your access to our server is blocked, you will have to send outgoing mail through their server instead.
In order to find out what your ISP's SMTP server is, simply visit their homepage and look for a support section, or call the phone number on your monthly bill. If you find you are unable to use your local ISP's mail server, it might be possible to get them to make an exception to the blocking for you.
If you have confirmed that your ISP is not blocking our SMTP server but are still unable to send mail, you may have an authorization problem.
To be able to send mail through the server you must first be authorized. How do you get authorized? Very simply! You must first log into the server through your pop (incoming email) account with your username and password using your favorite email client. After you logged in you have a period of 15 minutes to send mail. After this 15 minutes expires you will need to receive mail or authorize again. Here is a example:
POPAUTH is an addition to the current email system whereby sending of email through any given client server (commonly referred to as "relaying") is controlled by using the POP services to verify a user by username/password combination. This process is also known as POP-before-SMTP.
The following is a general overview of the operation of POPAUTH:
1) A user connects to their server to download their email. For this illustration, we will use user 'joe' on server 'myclient.com' with password 'joespassword'. The username/password/server information listed here is totally fictitious and used only for illustration purposes.
2) Using his username and password configured in his email software, 'joe' is authenticated by the POP server. 'joe' does not need to have email to be downloaded.
3) As soon as 'joe' is authenticated, his remote IP from which he is connecting is noted by the POP server.
4) joe's remote IP is now logged with the current time to a POPAUTH database.
For the next 15 minutes, 'joe' is able to send email through the server freely.
5) At the end of 15 minutes, joe's IP is removed from the POPAUTH database.
'joe' is no longer authenticated to send email through the server. 'joe' must now check his email for download in order to re-authenticate himself with the email server in order to send email again. If 'joe' does not authenticate himself before sending he will receive a 'Relaying Denied' error message.
For the mobile user (a user who moves from place to place over any given period of time) this is a great advantage as complicated access files no longer need to be updated and maintained. The email server now maintains this information directly without any intervetion necessary. To send email after moving from one IP to another, the mobile user need only check for new mail to gain access to sending email.
The entire process is seamless and self-maintaining, further reducing maintainance overhead by the server owner
