|
Preventing unauthorized mail relaying
Relaying occurs when Internet Services receives a piece of mail through SMTP that is not destined for a user on your FirstClass system.
If your site does not need to relay mail, we recommend that you disable it for your entire site on the Relaying subtab on the UCE/Spam tab.
If you choose this option, no SMTP server can relay off your site even if it provides the proper credentials (user ID and password - SMTP AUTH) or you have the server IP address in your Filters folder. This setup is easy to administer and extremely secure, as your system allows absolutely no SMTP relaying.
If you choose to allow relaying, you can control which individual users or groups can relay mail using the privileges on the User information form and the Group privileges form respectively. To set this up, you must follow this hierarchy:
• uncheck the "Disable all relaying, including SMTP AUTH and trusted IPs" field on the Relaying subtab on the UCE/Spam tab
• uncheck the "Allow mail relay" field on the All Users group form
• select the "Allow mail relay" field for any individual users or groups on the User information form and the Group privileges form respectively.
Allowing relaying for specific purposes
There are two scenarios where you may need to support relaying:
• you need to support POP3 or IMAP4 users on your system who send mail outside of your organization
• your Internet Services acts as the Internet contact point for a group of SMTP servers.
If your site needs to relay for POP3 or IMAP4 users
If you need to support POP3 or IMAP4 users who use your FirstClass server to relay, we recommend using SMTP AUTH, which is an extension to the SMTP protocol. Using this protocol, when a user sends mail using a POP3 or IMAP4 client, Internet Services will prompt the user for his login credentials (user ID and password authentication). Since FirstClass supports the SMTP AUTH protocol, we recommend that you instruct your users to enable it on their POP3 and IMAP4 clients.
Unless you explicitly disable relaying, Internet Services will do SMTP relaying for those who supply credentials.
What if I get blacklisted as an open relay?
Because of the proliferation of spam and the difficulty in stopping it, there are a number of organizations (including RBL suppliers) who aggressively identify open relay sites and add them to their blacklists. If your site is blacklisted, do the following:
1 Check your all yourrelay settings (Internet Services and user privileges).
You probably got blacklisted because spam came from your site. Lock things down using the methods outlined in this section and try to isolate the problem. If you can't locate the problem, contact the blocking organization and ask for help.
2 Ask the blocking organization to retest your site after you've located and fixed your relaying problem.
3 Check the trusted IP addresses in your filter documents.
There are some organizations, for example ORBS, that use flawed relay tests that assume your mail host is "sendmail". If you have configured your system correctly and you still fail their test you should try these options:
• reconfigure Internet Services to act more like sendmail
The main issue with these tests is that Internet Services absorbs some attempts to relay as if it might be delivering the message, when, in fact, it later delivers an NDN. Since the tests do not wait for the NDN, they are fooled into thinking the relay worked. By choosing Aliases only at "Inbound mail addressing" on the Advanced Directory form, you force Internet Services to reject these efforts as they come in:
 Using this option comes at the expense of your need to configure aliases (or set up automatic aliasing) for your Internet mail users.
• inform the blocking organization that you are not relaying, and prove it to them by having them try to relay off your site to some destination account.
The better organizations may respond reasonably to this sort of approach.
|
