GroupWise, Relaying Email, and Preventing Open Spam Relays

I get asked this question a lot:

I need to be able to relay mail off of my GroupWise server to outside users or systems, but GroupWise won't let me (or won't let me without authentication). This prevents me from doing what I need, how do I get around this? Can it be done?

In reality, this is very common. Many people need to relay mail from other internal, and sometimes even external systems. It might be a monitoring system, or custom app that sends notifications to customers. There are plenty of legitimate reasons, it just takes some simple configuration on the GroupWise Internet Agent (GWIA) to make it happen.

In the snippet of the log file above, you see that an internal device, 192.168.0.21 attempted to connect to GroupWise and relay to a gmail.com address. As this is not permitted, the action was denied. It's an expected response, but is something that is easily changed if you have a business need to allow relays.

A little about how GroupWise Relays works.

By default, and for security purposes, GroupWise requires authentication in order to relay off of the GWIA via SMTP. This is just smart because otherwise, anybody could have free access to your server and your system may become identified as what is called an "Open Relay". When this happens, your system attracts spammers to use and abuse your system to launch their spam attacks on others. It can get real ugly, and you don't want that. With the spambots out there constantly scanning for targets, your badly configured system could be identified as an open relay within 24 hours. So in a default configuration, GroupWise works exactly how you want and prevents this spam situation from happening.

However, you probably have a legitimate reason for wanting to use the GWIA as a springboard for sending messages. It's a very common situation, and GroupWise can handle it really nicely. All you have to do is change the configuration of the GWIA slightly and allow "Exceptions" to the standard relay prevention rule. These Exceptions are essentially instructions to let specific systems relay SMTP mail off of the GWIA without authentication, while remaining restricted to any host not in the exception list.

Instructions for Accessing Relay Control Dialog

1. Open ConsoleOne and connect to the GroupWise Domain where the GWIA resides.
2. Open the properties of the Internet Agent Gateway (GWIA).
3. Click on the "Access Control" tab (Drop-down) and select "SMTP Relay Settings".

You should see that the GWIA is configured to "Prevent Message Relaying".  You "could" just change it to "Allow Message Relaying", but you DO NOT WANT TO DO THIS.   I emphasize, Do NOT Change it to "Allow Message Relaying."  This will create an open relay which will result in your system being compromised. You will become blacklisted and it gets ugly really quick. You should see the dialog below:

Instructions for Allowing a System to use GroupWise as a Relay

Telling GroupWise to allow a system relay is easy. It's just a matter of adding an exception list for the system(s) that need to be able to relay messages.  Just follow these easy steps:

1. Click on the "Create" button
2. Enter the FROM and TO information into the Dialog and hit "Okay".   (I'll explain these options in better detail below, including some words of caution)
   
3. The entry will be populated into the list as depicted below.
4. Add as many exceptions to the list as you need.
5. When complete, hit "Apply".
6. The GWIA should restart automatically and put the settings in effect after a couple minutes. However, in some cases, you may need to restart the GWIA manually.
   

Notes

When defining the "FROM" and "TO" parameters for the list, it's important to understand what to put in the box.  The dialog is flexible, and allows IP addresses, DNS host names, and also Wildcards. But you MUST take caution when using wildcards because a badly placed wildcard can turn your system into an open relay.  You can populate the TO or FROM field based on the options below:

The "FROM" Field.

You can use any of the options below for the FROM field:

• IP Addresses.  You can use standard IP addresses of the "Sending" host, meaning the system you want to allow to relay from your GroupWise server. Using a standard IP address is my preference and is depicted above. Example: 192.168.0.34 or 10.2.4.1
• DNS Names. You can use the DNS name of the "Sending" host.  Personally, I do not like to use DNS names, but sometimes you may need to use DNS if you don't have control of the IP address or if there is a possibility that the IP address may change occasionally.  Generally, using DNS is better if the host that needs to relay is external to your system.  If you do use DNS names for internal systems, it's critical that your GroupWise server is able to resolve both internal and external DNS.  Example of a DNS name: vibe.redjuju.com
• IP Address Range. If you have multiple addresses that need to relay, you can define a range of addresses instead of creating multiple entries.  I normally don't use this method because it's rare to find the system IP addresses to be contiguous.  If the range includes addresses that shouldn't be allowed access, you do introduce a small amount of risk should one of those systems become compromised.  If you plan your IP address strategy correctly, using a range can simplify the configuration.  IP Address Range Example: 192.168.0.10-50 (This will allow all addresses from 192.168.0.10 through 192.168.0.50 to relay).
• Wildcards. You can use an asterisk as a wildcard combined with any of the above options if you need more flexibility. The wildcard works just like you would expect. However, be very careful, depending on how the wildcard is used, you could introduce risk into your system. Wildcard examples:
• 172.16.0.*  (Allow anything to relay if it is in the range of 172.16.0.x network)
• 172.* (Allow any address starting with 172.)
• *.redjuju.com (Allow any system from the redjuju.com domain to relay)
• *juju.com (Allow any system with juju.com at the end to relay.  systems from bluejuju.com, greenjuju.com, and redjuju.com could all relay in this example).
• * (Allow any system to relay - do not use this in the FROM field)

The TO Field:

You are allowed to populate the TO field with the same options as the FROM field. However, it's most common to use a single asterisk (*) to allow relay to all systems. This allows the mail to be relayed anywhere, and this is usually needed and perfectly acceptable. The main concern is that you properly configure the FROM field to only allow certain hosts to send.   You may have specific business reasons to for using other than a wildcard, perhaps you only want to be able to relay to other internal systems.  Of you have a specific host outside of your network or in the cloud, and that is the only system you want to be able to relay to while everything else should be denied. In those cases, use the same logic and formatting as the FROM field.

A Word of Caution about the FROM Field and Wildcards

If you abuse Wildcards (*) in the FROM field, you can easily introduce risk into your system. Consider the following scenarios:

• Using a Wildcard for your Network Subnet: Suppose your internal subnet is 192.168.0.0 with a 24bit subnet mask. You might think that it's okay to specify "192.168.0.*" in the FROM field. If someone inside tries to relay, it's legitimate, right?  Wrong. This is a bad assumption. Let me explain something that can happen and does happen frequently. What if a user with the IP address of 192.168.0.50 visits a malicious website and gets infected with a malware that sends spam? Even if you block workstations from SMTP traffic on your firewall, it's very possible (and likely) that the malware will scan the network for relay hosts and start blasting spam out to the GWIA, which will then forward the messages on because the wildcard grants it full permission. In no time, your internet bandwidth will be saturated, it will take you to a crawl, and within a few hours you will be completely blacklisted. This is not good for your business and essentially forces an email outage. You don't need that kind of problem.  This is why creating a wildcard entry for your entire subnet is generally a bad idea. I've personally seen this happen more times than I can count.
• Using a Wildcard Allow ALL (*): Suppose you set several Relay exceptions, but during troubleshooting you can't get things to work. You set a general Wildcard in the FROM field (*) to allow all, just to make sure it can work with that setting. Or maybe you just think that it's a good idea in general to use a full wildcard. Who knows.  If you leave it that way for any length of time, and if your GWIA sits on the perimeter of your network (meaning outside hosts can connect to it directly), within 24-48 hours it's very likely that your system will be identified as an open relay by a "bot" and will then this information will be propagated to spambots everywhere.  Within a few days, your GroupWise system will be sending out 100,000's, or even Millions of messages a day and you won't even know it until you get blacklisted or notice your internet bandwidth has been saturated.  With our regular customers, we try to take action to ensure this won't happen, but when a customer does end up on blacklists, this is one of the first things to check for.

Testing the New Relay Exceptions

It's not very difficult to verify if your configuration is working. Here are a few ways you can confirm the settings have taken effect.

From the Application Itself (Or from a Telnet Session)

In this case, I'll just use a Telnet session from the command line on my workstation. In the examples above, I used my workstation's IP address, so it's a great way to confirm. In the case of another application, you will receive some kind of feedback that tells you whether it's working or not. In the test depicted below, the GWIA accepted the RCPT TO: address even though it's not owned by this GroupWise server. This means it worked.

Check the GroupWise Logs

The original log file (First image in post) shows a rejected relay attempt. If the relay works, you should see a log entry confirming the relay was successful. The picture below corresponds to the Telnet test in the picture above. Note that it doesn't actually state that a "Relay" occurred, but it does change the link state to "Sending_Allowed" and you can see the message was accepted and passed on.

Definitions

Just for clarification, the following are definitions of a few terms used within this document.

GWIA

GroupWise Internet Agent. This is essentially the SMTP Gateway.

Relay

A "relay" is when email is sent to the GWIA (or any SMTP Gateway for that matter) and processed by the GWIA but the recipient is not an internal user. Therefore, the GWIA has to then figure out where the mail needs to go and send it on its way. Think of it as "Bouncing" the email off of your server to the recipients mail server. This works well because in general, SMTP servers are able to figure out where the mail needs to go, while many applications don't have this ability because they are not full SMTP engines.