|
Advanced Directory - Aliases Only vs. Exact Match Only / Allow Short Forms
There is a fundamental difference in how Internet Services handles inbound email under Aliases Only versus the other two options, Exact Match Only and Allow Short Forms, one that can have a significant impact on the performance of your FirstClass Server. This tech note will explain the advantages of running under Aliases Only, and the changes that will need to be made before making the switch.
On inbound internet mail, if your FirstClass Server is set for Exact Match or Allow Short Forms, a directory lookup must be done to determine if the intended email recipients are valid. As directory lookups are performed by the Server, not Internet Services, the end result is that Internet Services alone can not determine if an email address is valid or not, and must accept all mail for all domains it serves. This means that IS may be accepting hundreds and thousands of messages for email addresses which are not even valid, wasting time and resources.
Under Aliases Only, Internet Services can accept or reject messages immediately without involving the FirstClass Server in the process.
Exact Match Only
Here's a cropped inbound mail log of how IS handles this message:
SMTPCon-6: Inbound envelope recipient: testing123,FirstClass
Rcv: DATA
Snd: 354 Send your message, end with <CRLF>.<CRLF>
IS can't determine the validity of the email address, but it knows that it controls the testfirstclass.com domain, and so accepts the message. Whether this message is 5k or 50000k, IS accepts the message in it's entirety, and passes it to the server. The server then does a directory lookup against the email address, determines that there are no valid recipients, and generates a NDN (non-delivery notification), which it gives to IS to deliver to the original sender.
Configured this way (Exact Match), IS commits resources to accepting this invalid message, the server commits resources to doing a directory lookup and generating an NDN, and then IS has to deliver that NDN. Servers configured for Exact Match or Allow Short Forms will often find hundreds of NDN messages sitting in the IS mailbox waiting to be delivered, which can have an impact on the delivery of legitimate user-generated email.
Aliases Only
IS log of the same message sent to a server configured for Aliases Only:
Alias only addressing recipient testing123 NOT found in alias tables - rejecting.
Snd: 550 Invalid recipient address (no such address at this site)
Under Aliases Only, IS immediately rejects this message for having no valid recipients. From a resource standpoint, Aliases Only is by far the superior configuration.
Switching to Aliases Only
Valid addresses under Exact Match Only / Allow Short Forms may not be valid under Aliases Only. Take the following into consideration (and make the appropriate changes) before switching your server to Aliases Only:
1). Under Exact Match Only / Allow Short Forms, conferences can receive mail from the Internet automatically - conferencename@domain.com will almost always be valid (directory match). Under Aliases Only, conferences that are intended to receive internet mail must have a manually assigned alias (or aliases). The alias field is found in the conference permissions, under the Directory button:
2) Under Exact Match Only / Allow Short Forms, firstname_lastname@.. (such as john_doe@firstclass.com) is always a valid email address for your user accounts1, as it will find this name on the directory lookup. Under Aliases Only, the only addresses that are valid are those listed in the Mail Aliases field of your users' accounts. If the Mail Aliases field is blank, the automatic alias will be used. If Automatic Aliases is set to "do not create automatic aliases", this user will have no valid email addresses, and will not be able to receive internet
mail.**
Multiple addresses can be listed in the mail aliases field by using a comma as a separator (no spaces). The full domain only needs to be listed in cases where you want to assign a different domain than your server default (listed in Basic Internet Setup). The first email address listed will be the account's default alias (the address other people will see when they receive mail from this user.)
Automatic Aliases will only be assigned to user accounts when the mail aliases field for that account is blank. In this case, the userID becomes the default alias.
Make sure all users have the proper email aliases in place before switching your server to Aliases Only
If you need to assign aliases to many users, FirstClass Scripting will save you some time. The syntax for adding an alias (or aliases) to a user account is:
put user "userID" 1252 0 "alias1,alias2,etc"
Example:
To put those two aliases into his mail alias field via FirstClass Scripting, you would send the following message to batch admin:
put user "jdoe" 1252 0 "joe@testfirstclass.com,jdoe@testfirstclass.com"
Anything in the Mail Aliases field of Joe's account prior to this script being run will be replaced, not appended to.
For more information on FirstClass Scripting, do a search for "FirstClass Scripting" or "batch admin" within the FirstClass Client admin help or on this support site.
Once the appropriate mail alias changes have been made on your server, it's time to switch to Aliases Only.
A restart of Internet Services is required before the change to Aliases Only takes effect.
2. A server configured for Aliases Only with automatic aliases set to "do not create" is the simplest method of creating user accounts that can't receive internet mail. This is the standard setup for school districts that want to restrict students to internal mail only. For more information on restricting email, see http://www.firstclass.com/support/SupportCommentary/IS/TN-restricting%20email
|