GroupWise Internet Agents are relaying emails when they're not suppose to be relaying.

• GroupWise Internet Agent hosting SMTP, POP3, and IMAP are set to prevent relaying unless the email comes from a specific IP address. 
• Customer is using the --forceinboundauth on the GWIA to authenticate users with their GroupWise user ID and Password. 
• The users are NOT using a approved relaying IP address. 
• User has a virus on their workstation that's sending email from their GroupWise account when they login to the GWIA to retrieve email via POP or IMAP, the email is then relaying off the GWIA. 
• The GWIA prevents all other relaying.

The problem was a result of users logging into the GWIA to retrieve email for POP and IMAP, becuase of the use of the --forceinboundauth switch.  The code in the GWIA was designed to allow relaying from authorized users even if relaying was turned off.  To disable relaying for authorized users as well, use of the --disallowauthrelay switch is required.  This switch is located in the gwia.cfg file already, it just needs to be disabled.  Please be aware, that use of the disallowauthrelay will also prevent valid authenticated POP/IMAP users from sending to all external recipients, but they will still be allowed to send to internal GroupWise users.  This is due to the way POP/IMAP works and is considered a external source/email service.

A request to update the documentation for the forceinboundauth and disallowauthrelay switches, to include a clause about relaying and the disallowauthrelay and the implications of that switch, has been submitted to Novell's development.

A enhancement request has also been submitted to include more flexibility in controlling the IMAP/POP settings for use with the disallowauthrelay switch.  The enhancement is public and can be accessed at