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

ICC Meeting:

IFAS COMPUTER COORDINATORS
ACTIVE DIRECTORY SUBCOMMITTEE
(ICC-AD)

NOTES FROM Exchange Discussion portion of November 18th 2004 MEETING

A meeting of the ICC-AD subcommittee was held on Thursday, November 18th, 2004. The meeting was chaired and called to order by Steve Lasley, at little after 2:00 p.m. in Fifield room 1306.

PRESENT: Thirteen ICC members participated. Remote participants: Joel Parlin and Jack Kramer. On-site participants: David Bauldree, Dennis Brown, Marion Douglas, Chris Hughes, Dwight Jesseman, Nancy Johnson, Winnie Lante, Steve Lasley, Chris Leopold, David McKinney and Mark Ross.

STREAMING AUDIO: available here.

NOTES from Exchange Discussion portion:

Agendas were distributed and the meeting was called to order in Kevin Hill's absence by Steve Lasley at 2pm.

The Current IFAS Exchange Configuration

The meeting began with an excellent and lengthy explanation of our Exchange organization and settings by Dwight Jesseman. 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:

  • IF-SRV-EXCHFE01
  • IF-SRV-EXCHFE02
  • IF-SRV-EXCHFE03
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:
  • Outlook Web Access (OWA) over HTTPS
  • RPC over HTTPS (which allows a secure MAPI connection via commodity Internet without the need for a VPN)
  • Outlook Mobile Access (OMA) over HTTPS
  • IMAP over SSL (using port 993)
  • POP over SSL (using port 995)
  • and SMTP over SSL (using port 25)
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:

  • IF-SRV-EXCHBE01 (which handles mailboxes A-K)
  • IF-SRV-EXCHBE02 (which handles mailboxes L-Z)
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:
  • Storage Group 1 (100 MB Policy)
  • Storage Group 2 (1 GB Policy)
  • Storage Group 3 (Unlimited Policy)
  • Public Store (containing the IFAS public folders--replicated between the two back-end servers by the UF Exchange organization)
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:

  • %m@ifas.ufl.edu
  • %m@wec.ufl.edu (used to auto-create and auto-update appropriate email aliases for people within the WEC OU)
  • Junk Mail (used each night to automatically delete messages within the Junk Email folders that are older than 30 days)
  • Other Domains (lists other email domains on behalf of which we listen for incoming email)
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:

  • WEC Printer: 10.227.204.205
  • SRVIPS2: 128.227.96.41
  • SRVIPSS: 128.227.96.43
  • FRE_WEBFACT: 128.227.113.164
  • FPO1BLD: 128.227.134.19
  • ICS-SERVER: 128.227.134.160
  • FYCS-FILE1: 128.227.182.172
  • SRVWEB2: 128.227.242.140
  • SRVTASK3: 128.227.242.135
  • SRVIPS2T: 128.227.242.185
  • SRVIPSST: 128.227.242.190
  • SRVWEB: 128.227.242.200
  • IF-SRV-EXCHBE01: 128.227.252.42
  • IF-SRV-EXCHBE02: 128.227.252.43
  • IF-FPO-CTISENS: 150.176.204.50

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:

  • Filter recipients who are not in the Directory
  • Filter messages with blank sender
  • Drop connection if address matches filter
  • Block List Service sbk-xbl.spamhaus.org
  • Global Accept 128.227.0.0 (mail from anymachine (!) on campus will be delivered w/o being scored as spam. One obvious consequence is that e-mail forwarded from Gatorlink will not be scored; many IFAS users are thus receiving more spam than ever before.
  • Sending message size 51200 KB
  • Receiving message size 51200 KB
  • Recipient limits 5000
  • Message Block SCL. > 8 is set to no action (could be used to completely block high-rated spam, but this is unneeded and likely unwise)
  • Message SCL > 4 is set to move to Junk E-Mail Folder

The current deletion settings are:

  • Keep deleted items for 14 days
  • Keep deleted mailboxes for 30 days. We do not permanently delete mailboxes and items until the store has been backed up, and that is done weekly.

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:
  • When a virus is found: Attempt to clean (Note: it was decided that these just be deleted)
  • If cleaning succeeds: Log the item, Notify Administrator
  • If cleaning fails: Replace the item with an alert message
  • Custom malware actions: Delete the item, Log the item, Notify Administrators
Corrupt Content: (e.g. mal-formed headers)
  • Replace the item with an alert message
  • Quarantine the item, Log the item, Notify Administrators (Note: it was decided that these just be deleted)
Encrypted Content:
  • Replace the item with an alert message
  • Quarantine the item, Log the item, Notify Administrators
File Filtering (for attachments):
  • When no file filtering rule applies : Allow the item through
  • IFAS Blocked Attachment Rule
    • Replace the item with an alert message
    • Quarantine the item, Log the item, Notify Administrators
Scanner Control (for compressed file attachments):
  • Denial of Service Protection
    • Scan into maximum depth of nesting: 100
    • Do not expand files larger than: 100 MB
Custom Malware Actions:
  • Delete and log messages from mass mailers. ( Note: it was decided that all malware types should be set similarly.)

Exchange Global Address List (GAL) Naming Conventions

  • User: Last, First M.
  • Contact: Last, First M. – IFAS (identifies our contacts from others at UF--only used for non-UF people)
  • Contact that reflects a ListSrv List: . IFAS-XXX-L
  • Security Group: . IFAS-XXX ( Note: it was decided that all security groups in our AD structure should be renamed similarly for the sake of consistency.)
  • Distribution Group: . IFAS-XXX (used only for email-no permissioned assigned)
  • Query-based Distribution Group: . IFAS-XXX
  • Alias can be different - for example to reflect an older naming convention for distributions lists or to add Gatorlink as an alias to email (if possible)

Address Lists for the Global Address List (GAL)

  • Lists will be generated on a query of Custom Attribute 15 (set same as Network Managed By) Note: It was discussed that the available fields might be categorized for standard usages.
  • Create Mailbox vs. Establish Email Address
  • Mailboxes are for people that want a mailbox and an IFAS email address
  • Established emails are for people that want an IFAS email address that gets forwarded to a non-IFAS email account
  • Note: Mailboxes can only be forwarded to other GAL objects--they can't go out directly to an SMTP address.

Public Folders

  • There are no current standards.
  • CALS has placed a calendar in a public folder, which they are accessing through OWA. They have a website that points through OWA to the service account for that public folder. Thus you can now provide web access to a public calendar.

 
 

END OF EXCHANGE PORTION...

 
 

last edited 25 November 2004 by Steve Lasley