GroupWise Open Relay Crap

I started testing my GroupWise 7 server and found that I received a bounce back while trying to send to domains that block mail from servers in the ORDB (Open Relay DataBase).

Upon receiving this, one Saturday, I sent out a quick email scolding my tech who set up the gwia (GroupWise internet agent) and drove into work to fix it. I pulled up the area in ConsoleOne that contains the relay information and found a check in the box that reads “disable open relay”. Hmmm, you can’t get much clearer than that.

I quickly whipped up a web app that will attempt to relay mail off the server. No luck. So I went into my office and submitted the IP to ordb.org again for re-scan.

I was assuming that it was scanned while it was initially being set up, and that they had caught it in an open relay state.

A while later I received an email stating that it is still blocked by ORDB, because they still think its an open relay.

Puzzled I hit ordb.org faq to come with this…

My Novell GroupWise is not an open relay!

We’re sorry to say that it is. We are aware that GroupWise does not filter until after receiving the mail, but our test-method requires that at least one of our probes be delivered to its final destination before addition to the database occurs. Your server will not be added to the database just because it accepts the probe for later processing. Please see the section on securing your open relay for information on the latest patches for GroupWise. Additionally, please refer to this link for information about claims that ORDBs way of testing is flawed, when testing GroupWise and friends.
Additionally, a user has provided information that at least Groupwise6 (and possibly Groupwise5.x as well) may be vulnerable to various relaying exploits unless sufficiently patched. The patch you need to download is called fgwia63a.exe, and is so far only provided as a beta quality patch by Novell.

So, that wasn’t very helpful. I am running GroupWise 7 so that fits the “at least Groupwise6” requirement and I am running it on Suse Linux Enterprise Server so its safe to say that an exe patch isn’t going to work.

I could ask Novell about it, but support requests cost $500/, purchased in minimum quantities of 5.

On a number of forums I heard talk of a mysterios patch, but was unable to find any mention of it on the novell download site. I also read that Novell acknowledges that its a stupid way to handle relay attempts and that it would be fixed in GW6. Well, I’m on 7 and its not fixed.

The best ways I came up with to fix this are to use a incoming/outgoing relay host. Something free like exim or postfix. This also provides you with the ability to run antivirus and antispam on this host. Set up GroupWise to allow incoming and force outgoing relays through this host.

Or you can do what I did; purchase a Barracuda 300 from barracuda networks and use the same configuration as above.

My barracuda has gone through its initial testing very well and I’m quite fond of the web interface.

But its also very sad that GroupWise forces admins to do something like this. Its almost as if they intentionaly included this inadequacy in the hopes that you will have no choice, but to go to one of their channel partners for a fix… and spend more money.

Fix: ssh client timeouts in OS X

Using OS X and getting a lot of this?

Read from remote host blah.bligityblah.com: Connection reset by peer
Connection to blah.bligityblah.com closed.

So was I. At first I assumed it had to be Comcast, because Comcast falls into the auto scape goat category the same as Microsoft and the Bush Administration.

Before I became all accusatory and call and complain I did my home work.

The man page for ssh_config has the following to say.

TCPKeepAlive
Specifies whether the system should send TCP keepalive messages
to the other side. If they are sent, death of the connection or
crash of one of the machines will be properly noticed. However,
this means that connections will die if the route is down tempo-
rarily, and some people find it annoying.

The default is “yes” (to send TCP keepalive messages), and the
client will notice if the network goes down or the remote host
dies. This is important in scripts, and many users want it too.

To disable TCP keepalive messages, the value should be set to
“no”.

Sounds like that could be the problem. Issuing the following command as root will add the directive to the bottom of the ssh_config file and you should be good to go.

echo “TCPKeepAlive no” >> /etc/ssh_config

UPDATE: At least I thought you should be good to go. After running like that for a while I still lost my connection. Does anyone else have any insight into why this may be happening? I suspect Comcast, again. 🙂