Recently requested enhancements
Enhancement Requests added by Wiki Participants
GroupWise has some great internal security. Sometimes though, its just a little too good.
If one is in an environment subject to regulatory requirements (e.g. Sarbox, HIIPA, 1157, et. al. ad. nauseum), one may have a need, from time to time, to access a user mailbox for auditing or investigatory purposes. Generally, this must be done without the user's knowledge/consent.
But it can be difficult to gain access to a user's GroupWise mailbox on the live system, especially if the user has set a GroupWise password (which they have to do to use IMAP, POP or SMTP relay). Often, the "solution" is to lower the POA Security setting to "Low" and, if necessary, clear the user's password (which may tip them off to an investigation). Other methods involve laboriously copying to relevant files of the POA to another location and using GroupWise in "Direct Connect" mode; or defining a Proxy, which the user can detect/revoke if they look in the right place.
GroupWise needs to be able to define certain accounts as "Auditors". An "Auditor" can then be granted access to a user mailbox, allowing the "Auditor" to Proxy (perhaps with Read-Only rights) into the specific user mailbox without having to establish a Proxy in the user's Security settings. This would allow investigatory examinations of user mailboxes without having to lower security for the entire POA, or copy files, clear passwords, or take other actions that may reveal the investigation.
Since Auditing is a "backdoor" approch into a user's Groupwise directories, perhaps a similar and related function could be added as well for a group-wide calendar and address book. If a user can be audited without proxy then it would also be possible to assign group access to a shared user account. Everyone in the group would have access controls inherited from the group rights and extended control or filtered rights assigned individually. There are many workgroups and small businesses out there that would benefit greatly from both of these additions.
We all know and love ConsoleOne, but iManager is Novell's stated direction. It's time for GroupWise to move along with the rest and become manageable under iManager.
Legitimate concerns, such as access to the WPDOMAIN.DB file, exist, but they can be addressed. For example, much like v4.x GWADA.NLM was folded into the MTA and POA, the functionality needed to manipulate WPDOMAIN.DB can be folded into MTA, and the iManager plug-ins can be a front-end. The iManager server would communicate over TCP/IP with a listening port in GWMTA.NLM, and the GWMTA.NLM would execute the same changes now being made with ConsoleOne snap-ins.
UPDATE: Further investigations have revealed that iManager cannot be modified in such a way as to manipulate the wpdomain.db.
The new management will be done through the MTA SOAP interface that appeared in GroupWise 8 SP1. In GroupWise 8 this functionality is disabled while the new interface and management tools are developed.
Everyone thinks Exchange is the "900-pound gorilla of E-Mail", but it's not. sendmail has been around a lot longer and is much more widely deployed. Estimates range as high as 80% for the percentage all Internet E-Mail that is handled by a sendmail installation at least once in its journey. Rumor has it that sendmail front-ends Redmond's own Exchange environment.
sendmail is also deceptively powerful. Out-of-the-box it supports not just SMTP and ESMTP, but UUCP, Decnet and faxing capabilities. It is not a "mail gateway", but a "mail router", with the ability to handle multiple E-Mail protocols, just like most routers can handle TCP/IP, IPX, OSPF, BGP and RIP.
While much maligned as difficult to configure/manage, modern versions are really not that difficult. If the admin insists on hacking the .cf files directly, then yes, that's a nightmare, but there's been alternatives around for years.
In any event, sendmail offers a standardized interface to add a new protocol - the MAILER definitions. An example is ProcMail, which plugs into sendmail as a MAILER and can accept E-Mail directly from sendmail.
The same could be done for GroupWise - in place of a GWIA (specifically, the GWIA component that translates to/from SMTP-MIME) a MAILER module could be written for sendmail. This would allow sendmail to deliver E-Mail directly into the GroupWise system, and also allow sendmail to function as the SMTP daemon.
It would also allow GroupWise to take direct advantage of all the software out there that plugs into sendmail's MILTER interface. SpamAssassin, ClamAV and MIMEDefang are just a few examples.
By doing this, every sendmail server on the 'Net (and that's a LOT of sendmail servers) could become a front-end for GroupWise, and mail system admins will have less-complex infrastructure to maintain.
UNIX socket alternative to GWIA "Third Party" directory
Now that NetWare is POSIX-compliant and OES has been introduced, its time to stop limiting the "third party directory" function of GWIA to a directory. Support for using a UNIX socket interface should be added, and that will open up all sorts of software from the *NIX world to GWIA.
Again, as Novell moves its products into a *NIX sphere, some things done for other platforms become irrelevant, or worse, a problem.
For example, GWIA wraps its logfile entries. A CR/LF is added after about 72 characters and the rest of the entry is tacked on the end of a bunch of spaces used for indentation. If the line ends up being really long, a single log entry might be broken up by two or even three CF/LF and spaces combinations.
That makes it impossible to reliably use tools like grep on GWIA logfiles. Or the admin is reduced to using tools like sed or awk to chop out the excess baggage before they can be analyzed. But there's no reason for that behavior in the first place - it might look good on the screen, but its just clutter in the logfile. Its also inconsistent with the POA and MTA logging styles. So let the admin turn it off.
To get the log file lines to fit on the screen, message thread ID's were truncated - showing the last three characters of a thread ID instead of the whole thread ID. If we had the whole thread ID, we could use grep with much greater efficiency.
Finally, the GroupWe Agents should have the ability to log via the standard *NIX syslog daemon, and not be limited to writing to local logfiles. Again, Novell is moving into a *NIX world, and some components of its products shouldn't be allowed to straggle behind.
Suppress automatic display of next message in QuickViewer
When using the QuickViewer, as a Groupwise message is moved or deleted, the next message is automatically opened and tagged as "read" even if I don't have time to deal with it. This often causes the message to be ignored the next time I open Groupwise. This default action should be changed, or made optional.
GROUPWISE/NetMail/Hula - SPAM
Probably just a reminder - below is one trade mag view:
We need a solution, and it's becoming a bottom-line issue. I was glad to see that this week Yahoo and Cisco announced they are combining their anti-spam efforts -- Yahoo's Domainkeys and Cisco's Internet Identified Mail (IIM) -- as, you guessed it, Domainkeys Identified Mail. The two use similar technologies that attach digital signatures to mail that are checked to ensure that the message was actually sent from the domain named in the message's "from" address.
Jimmy Kuo is right when he says that the ability to forge a "from" address, which is used on most spam, is the thing that makes e-mail a highway into your PC.
Tell vendors that, if they're not part of the solution, they're part of the problem.
Yahoo and Google's Gmail and other companies have implemented Domainkeys.
Would be great to have image support in the Signatures on the Linux version of the Groupwise Client.