ICC Home  /  Members  /  Meetings  /  Peer Support  /  Documentation  /  Projects

The Current IFAS Exchange Configuration

On 18 Nov 2004, Dwight Jesseman provided a lengthy explanation of our Exchange organization and settings. Two handouts were made available:

  1. Diagram of the IFAS Exchange Organization (Visio Diagram - 439KB) If you do not have Visio, you may download a copy of the Visio Viewer application here
  2. Discription of our McAfee Group Shield settings and of our Exchange Global Address List (GAL) Naming Convention (Word Document - 41KB)

Front-End Exchange Servers

These consist of three machines using GroupShield 6 anti-virus software configured via ePO:

which utilize network load-balancing, the address (cname) of which is email.ifas.ufl.edu. This allows the supported POP, IMAP, SMTP, and webmail services all to have the same IP address of "email.ifas.ufl.edu". These servers support: Thus, all these services use a secure channel for communication of access credentials; no usernames and passwords are sent over the wire via clear-text. Because our users have traditionally used an address of http:/webmail.ifas.ufl.edu for webmail, Dwight has configured that to redirect to the secure site https://email.ifas.ufl.edu for OWA. Dwight has provided documentation how to configure Outlook 2003 for RPC over HTTPS. Outlook 2003 is necessary for using this and Windows XP SP2 is recommended; you can run this with Windows XP SP1, but a hotfix is required. (Note: Microsoft also has a good article on How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003 .)

Most of our e-mail protocols use the front-end servers for both inbound and outbound traffic. Currently, for those using a MAPI connection (i.e., Outlook), outbound traffic goes directly from the back-end servers. Dwight intends to change this so that such traffic is redirected through the front-end servers as well--as soon as a particular anomaly with that configuration has been investigated. This will be one step forward in allowing us to support sender-ID in some future configuration.

The front-end servers hold the SMTP connectors, and those are where the Intelligent Messaging Filters (IMF) are enabled to accept what is set at the UF level so we can take advantage of IMF as our anti-spam solution. The front-end servers are what actually process mail for IMF. Because of this configuration, we have no server-side mechanism to prevent internal spamming from one MAPI user to another.

Back-End Exchange Servers

We have two back-end Exchange servers using GroupShield 6 anti-virus software configured via ePO:

These are where the actual mailbox stores reside. The individual stores are organized into "storage groups" upon which storage quotas are placed. There are four groups on each server: Groups 1 & 2 each currently consist of a pair of individual 40 GB mail stores and Group 3 currently contains a single 40GB mail store--but additional stores can be added to each group as needed. The mail stores comprise the actual database in which the mail resides

Mark Ross mentioned that he currently has email distribution lists within public folders and was wondering how best to handle those in the future. Dwight suggested using dynamic distributions lists would be best. This would be based on user accounts in AD along with contact accounts for outside contacts. Putting those in an OU would permit dynamic distribution lists to be created and maintained. Chris Hughes mentioned that another possibility may reside in Microsoft's Automatic Distribution List Management (AutoDL). This allows a a web-browser interface to group management within AD.

Recipient Update Policies (RUPs) are necessary, important and useful Exchange components which can be used in various ways for email handling. We currently have four RUPs configured:

RUPs can be used to handle multiple e-mail domains within our organization. A RUP must be configured for any domain that is to receive mail. RUPs can potentially create appropriate email addresses automatically with the associated alias when a mailbox is created. If the account name was changed, the RUP could then, again, automatically update a corresponding email address; Dwight hopes to be able to use this feature down-the-road for IFAS. WEC can do this already for their wec.ufl.edu email domain because all their users are in an individual OU. RUPs are also how we implement the cleaning out of old messages from people's "Junk Email" folders.

We have a 128.227.252.28/27 network for our Exchange servers. All those are registered SMTP servers with UF and have the ability to relay SMTP trafffic outside of UF's core. If there are other people who need to be able to send outbound from UF from servers they are running within IFAS, UF has asked them to use IFAS servers as relays. We currently allow the following:

The SMTP connectors (recipient and sender) on the front-end servers determine how messaging is handled. Those are set at the UF level, however; we basically just have the ability to accept or not accept what UF offers. We are currently set to inherit those because without that we wouldn't be able to use IMF. A potential problem exists in that UF is currently using the spamhaus RBL that could cause our clients email delivery problems.

The current message delivery rules are set to:

The current deletion settings are:

Dwight will work with Mike Kanofsky to narrow down the global accept range and to remore the RBL usage. The latter may be difficult because UF is using that as one component of spam scoring (weighted at 3.6 points) and UF is blocking mail that scores 6 or higher on their scale.

McAfee GroupShield 6.0 Current Settings

Anti-Virus:Corrupt Content: (e.g. mal-formed headers) Encrypted Content:File Filtering (for attachments):Scanner Control (for compressed file attachments):Custom Malware Actions:

Exchange Global Address List (GAL) Naming Conventions

Address Lists for the Global Address List (GAL)

Public Folders

last edited 25 February 2005 by Steve Lasley