Like many other schools we have a demo account for our Luminis implementation. Not wishing to have people use the account to send out spam I arranged with our mail administrator to not have a mailbox created for this userid (we use external mail and authentication). This effectively prevents the user from using the e-mail channel or e-mail icon after logging into JUMP.
However we have just discovered that there are at least two other ways this demo account can send e-mail. One is to click on the Help Icon and then select the Support link. This brings up a compose screen with the To address auto populated with your Luminis admin e-mail, but does allow the user to pass additional e-mail addresses (or replace the supplied address).
The other way is to join a group and then e-mail someone in the group. You will get a similar screen, however in this case the person you are e-mailing will be added to the Bcc field, allowing you to specify additional addresses on the To line.
Have any of you also discovered this? If so what steps did you take to circumvent this issue?
Comments
Demo accounts and e-mail issues
What I did was create a Guest role, then assign that role to all of the demo accounts. I then took out any of the tabs I didn't want shown in the fragment manager. We don't want guests using the library tab for example. Then in our icon evaluator program, anytime that a guest logs in, it takes all icons off except for the help and logout. This keeps them out of groups, calender, email, and our custom links that we added.
**I didn't catch that they could get into email from help. In our icon evaluator we could take that out too for the guest roles.
Same as us, however...
With your guest account if you click on Help (unless you suppress that icon) and then on Support you will be able to send e-mails. Even if you remove that icon as a guest you can use the following URL:
http://your.server.edu/cp/email/composeBody?function=new&subject=SPAM&to=you@google.com
So the crux of the problem is with this servlet.
Servlet for e-mail
com.pipeline.email.EmailServlet appears to be the controlling servlet for this screen within Luminis. It also makes heavy use of the templates found in /opt/luminis/webapps/luminis/WEB-INF/templates/email specifically compose.thtml for the compose screen.
These templates do offer some basic flow control (if...else...) so if there was a way to check what the e-mail address is at the template level we could then prevent the To, CC, and BCC fields appearing, or just disable the composition screen
support email for IV
We're on IV and there wasn't anything in that folder. It looks like the page controlling this is: /opt/luminis/webapps/luminis/jsp/email/compose.jsp
Where we have just 1 email address for support, we could just take out the text fields and just display the help desk's email address, and add in a hidden input field with that value.
Also, this:
http://your.server.edu/cp/email/composeBody?function=new&subject=SPAM&to=you@google.com
doesn't work on IV. Trying it gives you the Access Denied page in Luminis. Maybe this is a fix for the problem?