Possible bug - problem reading addresses on forged email

We use an outside company to host our online classes. When a student or
professor logs into this site they have the ability to send an email. Parts
of the mime header are forged so that it appears to come from the student,
is sent to the professor, and is CC'ed to the student. Below is an example
of how one can manually enter the SMTP commands to duplicate it.

HELO schoolemail.org
MAIL FROM: email@schoolemail.org
RCPT TO: user@example.com
DATA
From: "admin@example.com" <email@schoolemail.org>
To: <user@example.com>
CC: <admin@example.com>
Reply-To: <admin@example.com>
Errors-To: <admin@example.com>
Subject: Test Email
This is a test.
..
QUIT


If the email is sent in this form, where the MAIL FROM doesn't match the
Reply-To and the CC points to the same email address as the Reply-To, and
the user tries to reply to it using the Groupwise client it will populate
the CC field but leave the TO field empty. If the user uses Groupwise
Webaccess and replies to this email it will leave the CC field empty and
populate the TO field with the bogus email@schoolemail.org, which results in
the user thinking the email was sent to the intended destination but in fact
went into a black hole.

If the email lacks a CC and the user replies to this email Groupwise will
read the Reply-To address as intended. If the sender email address is not
forged (that is, the MAIL FROM and HELO lines refer to the same domain as
the CC and Reply-To lines) and the user replies to the email Groupwise will
read the Reply-To correctly.

I realize this is a pretty specific set of conditions in order to have this
error. Has anyone run into this before? Does anyone know a solution? Is
this a bug to report to Novell? We're running Groupwise 7 SP2 HP1a (though
this has been happening at least back to GW 7 SP1) on a Netware 6.5 SP6
server.


Matthew