Novell is now a part of Micro Focus

Let Users Receive, but not Send

Novell Cool Solutions: Trench

Digg This - Slashdot This

Posted: 5 Apr 2001

Versions: GroupWise 5.5 EP, GroupWise 6

Recently we posted this Open Call for solutions to this problem:

Open Call: We've had a few requests for this, and we're stumped. Anyone out there know an easy way of stopping a user with a GroupWise account from sending e-mails? They need to be able to receive, just not send. We thought it was an odd request, but several sys admins have this same need so there's probably some really good reason to do this. If you know a cool solution for this, let us know.

We received a whole boatload of great ideas. You guys are very creative, and it seems there are many ways to skin this particular cat. Check these out, and if you have any to add, please let us know.


Rick Johnston

I am first going to assume that you looking for a solution whereby the user CAN send/receive internal GroupWise email but CANNOT send external email to the internet while being able to receive email from the internet. If this is the scenerio, then I have a solution for you.

Configure the ACCESS CONTROL tab of the GroupWise Internet Agent (GWIA) to control user access to internet email. Complete the following steps:

  1. Create a DEFAULT Class of Service with the following properties:
    • SMTP Incoming -> prevent incoming messages
    • SMTP Outgoing -> prevent outgoing messages
    • IMAP -> prevent access
    • POP3 -> prevent access
  2. Make the group EVERYONE a member of this Class of Service. This will deny access to all users from internet email services.
  3. Create two user groups, one for full internet email access and the other for receive only access and add the applicable user accounts to the individual user groups.
  4. Then create a FULL ACCESS Class of Service with the following properties:
    • SMTP Incoming -> allow incoming messages
    • SMTP Outgoing -> allow outgoing messages
    • IMAP -> allow access
    • POP3 -> allow access
  5. Make the group you created for full internet email access a member of this Class of Service. This will allow access to internet email for all members of this group.
  6. Next create a RECEIVE ONLY ACCESS Class of Service with the following properties:
    • SMTP Incoming -> allow incoming messages
    • SMTP Outgoing -> prevent outgoing messages
    • IMAP -> prevent access
    • POP3 -> prevent access
  7. Make the group you created for receive only internet email access a member of this Class of Service. This will allow receive only access to internet email for all members of this group.

With this solution members of the full access group will be able to send and receive internet email normally, while members of the receive only group will only receive email from the internet and can send or receive email to/from internal GroupWise users. When a receive only user tries to send an email message destined for an external internet email user, it will be disgarded when it gets to the GWIA. This solution works with any version of GroupWise that uses the GroupWise Internet Agent.

If you have any questions you may contact Rick at

Fred Lyles

Disabling a GroupWise user account will prevent the user from logging in to his/her account, but email will still be delivered to that account.

If you have any questions you may contact Fred at

Brad Frazer

Just make multiple service classes under GWIA access control.

If you have any questions you may contact Brad at

Heather Eyre

Use proxy and only give read access to mail.

If you have any questions you may contact Heather at

Steve Watne

Could you only give them access to an account through proxy, and limit the rights? Maybe lock down their client first (no rights)?

Another thought was to give that person GW remote access only and somehow limit it's ability to send - maybe through a gateway account that dosn't have rights to create new files, but stll can browse and read then from the PO.

Or, set up a POA - have incorrect TCP/IP address to the MTA so it doesn't deliver or send mail, but users can still authenticate to it. User accouts there would be just to get a client running and then proxy to another user account on another, usable POA, only the rights are limited to read, but not write mail.

If you have any questions you may contact Steve at

Jay Martin & Jason Broekman

Make a special PO and ONLY give read rights to the data bases.

The specific directories to receive the read only right for an account to only receive mail are:

  • wpcsout
  • ofviews
  • ofuser
  • offiles
  • ofmsg
  • software ? f)

You can make a PO to only house this type of account and make it connect direct to the database.

If you have any questions you may contact Jay at

Peter Bruno

If the user is accessing their email using UNC you might be able to remove permissions to the wpcsout directory so that they can't create new emails.

Or you could create a POA that doesn't have outbound links to the MTA or adjust the account that the POA logs into NDS with - and remove permissions to the 4 & 5 wpcsout directory

If you have any questions you may contact Peter at

Mark Nielsen

Well, it's not the complete solution but you can block an ID from sending email outside of the company. Guinevere can do this very easily and the GWIA does this as well (reverse TID 2932485). Quite simply, this can't be done in the current design because Novell designed a messaging system that does not allow this. If this 'feature' (sending) was disabled, things such as tracking would need to be disabled as well.

If you have any questions you may contact Mark at

David Muldoon

I am the GroupWise Administrator for a large banking corporation in the northeast. We have some different regulations that we must follow that most companies won't. However, we configure some accounts for "receive only" when we need to by using a third-party product.

We have a product by Content Technologies called Mimesweeper. [Editor's Note: This product is now owned by Baltimore Technologies.] It is really used for Anti-Virus tasks, but it also offers more options. We use this product as our relay agent for our GWIA that communicates to the internet. This application requires all users to have account rights to pass messages beyond it to the Internet and also to receive messages from the Internet. We configure the accounts that we want only to be able to receive mail at this utility.

However, this scenario only restricts Internet email, not internal email.

If you have any questions you may contact David at dmuldoon@MANDTBANK.COM

Juergen Dischner

Create a new class of service in the (GWIA) ACCESS Control tab.
Determine the user and establish their rights (SMTP-INPUT,SMTP-OUTPUT.....).

If you have any questions you may contact Juergen at

Eric Toll, CNE 5, GroupWise 5.5 CNA

Set up user with GW account in NWAdmin. Instead of installing GW Client, install POP Client like Pegasus. Now they will be accessing email from the GWIA not the POA.

In GW Admin, deny SMTP sending of any kind for this GroupWise client.

They may pop in and get messages. If the client tries to deliver a message, GWIA will see the Deny SMTP Send for this user object and not oblige. The Undeliverable can go to the Admin for a heads up notification of attempted sending activity.

Don't forget to modify the GroupWise client directory so they can install and send messages internally.

If you have any questions you may contact Eric at

Paul Caron

Guinevere can do this. You set up an outgoing filter rule to delete messages from a particular user (you could send them elsewhere, to an admin, supervisor, or even archive them). ~ $500 bucks - you can't go wrong with that kinda money these days. And Guinevere will allow you to interrogate your files that are attached to your email for viruses (you need an antivirus program for this, but Guinevere will use it to probe your email for virus activity).

I don't know how to do this solely within GroupWise, but the benefits of using Guinevere far outweigh its cost.

If you have any questions you may contact Paul at

Nicholas Hobbs

A few kludges and not necessarily clean fixes. But they all work.

  1. To stop a user sending to users in the address book, remove the address book from their Mail Control Panel under the Addressing tab. This will not stop them from receiving mail. This will only work if the users are dedicated to a particular PC.

    Note: This may not stop them sending internet e-mail depending on your mail setup. You may have to change their rights to the GWIA.

  2. This will work but may have a bad side effect. Set the users' Tools,Options,Send,Delay Delivery to 30/12/2099 option. This will still put the mail into the POA however.
  3. Similar to 2 in a way. Force the users' mailboxes to send only low priority mail and connect them to a dedicated POA that never processes low priority messages. (Yuck, I know...)

With 2 and 3, You then set the POA to run a reduce and expire on the specified mailboxes every week/night/month for the specified users' outboxes.

If you have any questions you may contact Nicholas at

John Neall

How about creating two accounts? One to receive the mail and another to proxy into that account with no rights to send. The end user would have to start one account and then proxy to the other. Depending on why they want this restriction( if they don't want replies to come from a specific address, such as webmaster, but still want the account monitored), this might work.

How about modifying all the views to remove the create message and reply to message buttons. Time consuming, but it might work.....

If you have any questions you may contact John at

Michael Byrd

I have not tried this, but if I had that problem I would setup a separate Post Office for these users and then set and lock the client options for that Post Office so that if they tried to send an email the message would be delayed for 999 days and \or set the Expiration date to 0 days.

Michael Hawksworth

Since external is supported in GWIA I expect you mean internal mail. Only way I can see for internal is to lock out the menu options, remove the Send icon and replace the normal mail forms with custom forms without reply options.

Either that or employ someone you trust!

If you have any questions you may contact Michael at

Greg Beckmeyer

How about setting up a second account for the user to actually log into, which has proxy access to the account in which the user receives mail? You could change the password on the primary account so the user can no longer access it directly, and then set any rights you want using proxy access.

If you have any questions you may contact Greg at

Peter Bruno

Michael Byrd was on the right track, but you don't have to create a separate PO for the users. You can change client options on a per user basis. As Michael said, change the client options to delay delivery for, say, 7 days and expiration for 1 day. You will also probably want to change Status Tracking options so that a sent item is not created, and don't forget to lock everything you have changed.

Charles Huber

I agree more with the "comments" section on this topic - WHY is this needed? However, I too have received such requests from some areas.

I can't see a whole solution with the suggestions given. Proxying is inherently wrong - if they have an account to proxy FROM, they can send mail. Configuring the desktop client without Address Book components doesn't stop people from replying, using explicit IDs, or finding another desktop. (Hey, we don't trust these people, right?) Likewise, forcing them to use POP3 means they need a password - and can therefore get in from a client-capable machine or via WebAccess with full sending functionality.

Though it hasn't been worth the time to try, it seems to me that you could put these untrusted users on their own domain, which also has a GWIA. Then setup an external/foreign domain (INET, for example), and configure links so that this domain only sends TO all other internal domains indirectly through INET (therefore, through the local GWIA). Then you can use a third-party product like Guinevere or just prevent outgoing messages. Make sure you keep a direct link from your primary and real GWIA domains, so admin changes and inbound mail get to these users.

The net result should be that users in this domain can receive all inbound e-mail (routed normally from your other domains), but all outbound mail is forced through a customized GWIA that filters (or stops) undesired messages. This way, the restrictions are set on their account, not dependent on a uniquely configured workstation or client they can get around. They should be able to get the same results whether using the GW client, Outlook, WebAccess, pop3, or imap4 for access.

If anybody has the time & actually tries this, let me know how close I've come! This could get us another 700 accounts of receive-only e-mail if it works!

If you have any questions you may contact Charles at

Robert Pyatt

This can work well with less smart users on a dial up account.

Create a rule that deletes sent items.

The only problem is that a smart user would be able to get round this quite easily, but it can work rather well in some instances.

Debbie Prette

We are using a similar system that Rick Johnston is using but here are a few differences:

We have set up GroupWise Distribution Lists for each type of email rights. As the administrator in NWADMIN we place each user into a list when they are added to the GroupWise system and we can track who has what rights. Each group is then allowed access in GWIA Access Control. Here are our groups:

Internet Email Admin - Allows In/Out and Oversize Attachments (Limited to Administrators and Special Exceptions)

Internet Email Full - Allows In/Out and Limits Attachments to 120k (No junk emails are allowed in - oversize are dumped into GWPROB folder)

Internet Email Pager - Allows Outgoing only to a specific email address - our AlphaPager Communication Service Provider

Internet Email No Access - Users who have no access to Internet Email

As administrators who have to protect the entire network from viruses and stay within a certain number of licenses we can easily see the number of users in each group and easily change their rights but not exceed our license agreements.

I really appreciate this area of Cool Solutions and look forward to ideas from other administrators.

If you have any questions you may contact Debbie at

Chris Baker

  1. Set up an account for the user that does not have external email permissions.
  2. Set up another account that the sys admin controls with external email permissions and the user's email address or alias.
  3. Set a rule on this account to forward any mail received to the user's account that they log in with.

In this way the user does not need to have proxy access to the account with the permissions.

If you have any questions you may contact Chris at

Michel Tode

I assume we all know about the GWIA option by now. [GWIA can be configured to control who can send out, and who can receive. Look here in the documentation.]

GroupWise is not able to restrict the sending of internal messages. Yes, it's possible by restricting the File-system rights, but many customers want to use TCP/IP and they DON'T want error messages on the client side.

Robert Ridley

(Novell Primary Support Engineer)

The best way to accomplish this would be to create a post office for just these users, then setup WebAccess (5.5 EP recommended) for them. You would need to modify some of the template files (.htt) that give them access to the send, forward, reply or attach functions. Finally you would have to configure an IP filter (using FILTCFG.NLM and IPFLT.NLM) to limit network access to the TCP port of the post office (i.e. only from other netware servers), so they can't connect through the regular GroupWise client. This way you can still have a pure IP environment within GroupWise and give these users read-only email access anywhere on the network. I think this beats having to setup extra GWIA access rules or having users connect to a post office in direct connect mode.

Note: I have not tried this, but I have seen different parts of this idea implemented. There should be no problem getting this plan to work. Some of the template files that should be modified are: msgaction.htt, and send.htt (but there may be others).

Ed Hanley

(Novell Consulting Minneapolis)

Doing this from the GroupWise Windows client perspective can be accomplished by coding a GroupWise C3PO program that intercepts the "send mail" functionality via a "Token" event capture when composing a new mail message. The APIs of NewMail(), NewNote(), NewPhone(), NewTask(), NewTopic(), SendAppointment(), SendMail(), SendNote(), SendPhone(), SendTask(), SendURL() could be used to accomplish this solution. This way you can pop up a dialogue box that states that "Sending functionality has been disabled".

You can have Novell Consulting code such a solution for you if your in-house staff does not have the expertise.

If WebAccess is involved, customization of that environment will also have to be done. You will have to add some attribute to the users NDS User object or define a GroupWise "Administrator-Defined Field" that flags that user as one who is not allowed to send email messages. This same attribute can be used by the above C3PO solution as well.

Also, do not offer POP3 or IMAP4 services and don't allow your users to install the OutLook client with our GroupWise OutLook Plug-In. More measures would have to be done for these client access methods.


Armando Luna

It's called a "memo'. This is so stupid! Why even give a person e-mail if it's not functional? This seems a function of an overbearing sys admin and strict corporate culture.

Kenneth Etter

I don't have a solution....just writing to let you know that I could use the solution if it is found. I just received a request from management regarding this capability. For the time being, we have partially solved our problem by stopping email at the GWIA. But we still need the ability to make some accounts receive only. I hope you are able to find a solution for this. Thank you.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates