Jason Mader
Virginia Campus networks

Internet messaging

I am the mail administrator for these messaging domains at GW:

You can send me email at postmaster@anydomain.

Messaging service is powered by CommuniGate Pro from Stalker Software. This is a great package.

2001-8-23 memo: As of October 1st, 2001, the GW electronic mail policy will be in effect that requires all GW employees (faculty and staff) to have e-mail accounts on the GWMail enterprise e-mail system. That's fine. Use RPOP to retrieve your GWMail and store it in your Virginia Campus account.

I also suggest that if you use gwu.edu for your e-mail address that you set the Reply-to address to be your va.gwu.edu or ncac.gwu.edu address. And you should configure your Virginia Campus account to be your preferred e-mail address in the GW Banner System.

2003-01-28: In addition to a 36 hour planned outage early this month, it looks like GWMail is down for at least 110 hours for the disk failures. That's 146 hours of downtime this calendar year! GWMail can only expect to achieve 98.33% availability this year. Not very good for an “enterprise” e-mail system.

2003-06-23: Stalker Software Takes Messaging and Collaboration on the Road with CommuniGate Pro v4.1 with Groupware

2003-12-08: Looks like another bad day for GWMail; down another 10 hours 45 minutes.

2003-12-12: A planned 56 hour outage Dec 20 - 22 for GWMail will bring the tally to 176.75 hrs this year. 97.98% availability. Wow, that's terrible.

2004-07-26: Stalker Software Unveils CommuniGate Pro v.4.2 Real-Time Communications for Advanced Enterprise Messaging

This is a reference page. For setup information, see the Quick Reference Guide for GW-TRI and Virginia Campus messaging users.

Features available on our messaging server

In addition to the messaging server function provided by CommuniGate Pro, I have also provided:

Anti-spam strategy

  1. Private and reserved IP addresses are blocked on the SMTP listeners.
  2. Connections to port 25 are initially delayed 26 seconds (to accomodate verizon.net), it causes many spam and virus smtp engines to disconnect before ever starting the smtp session. Senders that don't wait for the prompt are rejected. This drops a lot of senders.
  3. NO UCE is displayed on the 220 line.
  4. The mail server is not an open relay for any IP address, every sender must authenticate before relaying.
  5. HELO address is verified for all unauthenticated SMTP connections.
  6. Return-path is verified for all unauthenticated SMTP connections, messages with bad return-paths are rejected.
  7. Certain spoofable address ranges are blacklisted, messages claiming to be from those address ranges are rejected.
  8. Agressive address harvesting, errors, result in temporary blacklisting of the IP address.
  9. Messages are rejected if the senders domain does not match SPF records.
  10. Messages are scanned by a virus filter. The virus filter will notify the receipient, but does not notify the sender, to prevent anti-virus spamming. The original message with virus is destroyed.
  11. Remaining messages are then scanned by a spam filter that uses regularly updated rules and a real-time black hole list to provide a confidence score. Users can filter messages based on this confidence score.
  12. Sender Policy Framework is implemented for all the Domains. Since the mail server can be used as a relay from anywhere, it's the only authorized sender and unauthenticated messages with a local return-path are rejected.

Comment on using CommuniGate Pro with dnscache

I found the default DNR settings for CommuniGate Pro 3.5 did not mesh with the behavior of a local cache when all the nameservers of a domain where unavailable. The defaults from initial time-out of 7 seconds and 5 retries lead to:

3 DNR got response from [127.0.0.1] for an unqueued request 2492; discarded These defaults make CommuniGate Pro wait 105 seconds, but dnscache is spending 60 seconds on each nameserver trying to resolve the query (see the dns_transmit library interface). The localhost interface is reliable so I want to avoid restarting the query while dnscache is still working. Most domains will have two or three nameservers but it's not good enough to set the initial time-out to 2 or 3 minutes because a DNS server failure message will come just after CommuniGate Pro stops waiting for the reply. So I changed the initial time-out to 10 minutes, reduced the retry limit to 1, and for good measure increased the concurrent requests to 15.

Now CommuniGate Pro will wait long enough for dnscache to time-out on nine unavailable nameservers during a request and still accept a DNS server failure response. In months of regular operation on the Virginia Campus mailserver the 10 minute time-out has proved to be sufficient.

Update (2003-11-20): an unqueued request came in at 10 minutes, 42.5 seconds. So far in the field a minimum time-out of 643 seconds would have been sufficient for my most fringe case.

Generally 10 to 12 nameservers are considered the maximum that will fit into a single UDP packet (there are 13 root servers). dnscache will try to contact at most 16 nameservers. Stalker: An initial time-out of 961 seconds would be perfect. Another reasonable upper bound, so you don't have unexpected lookup failures, might also be an initial time-out of 3 minutes and 3 retries.

Take note that the DNR settings effect RBL queries as well and if you don't run your RBL DNS server on the same machine it will delay mail when the RBL DNS server is not reachable.

If the mail server is busy and more than 15 concurrent requests are needed, my feeling is that the safest thing to do is to increase MAXTCP in dnscache.c to five more than the DNR setting you need.

OpenSSH keyword LoginGraceTime also should be set to 961 seconds.

Comment setting DNS and CommuniGate Pro domains

When using Kerberos on a CGP domain, typically the Kerberos realm should match the CGP Domain. Use an alias, such as "mail.domain" on the domain for all SSL certificates. This becomes crucial to the client connecting and getting the Kerberos ticket for the server. The reverse of the IP should be the same as the forward, making it "mail.domain".

Comment on filtering at CommuniGate Pro listeners

See RFC 2827 and the DDoS Mediation Action List.

Based on those guidelines, it is considered good practice to filter all private and reserved addresses. Do this in addition to packet filtering on the mail server network interfaces.

; private and reserved address ranges
0.0.0.1-0.255.255.255
10.0.0.0-10.255.255.255
127.0.0.0-127.255.255.255
169.254.0.0-169.254.255.255
172.16.0.0-172.31.255.255
192.0.2.0-192.0.2.255
192.168.0.0-192.168.255.255
224.0.0.0-239.255.255.255
240.0.0.0-247.255.255.255
248.0.0.0-255.255.255.255

Other resources

See my guidelines for writing CommuniGate Pro WSSP.

CGP WebSkins
CGP: WebUser Interface