Early in July the University further increased its efforts to reduce spam and emails containing viruses and other malware from reaching University email accounts. Graphical evidence at http://rattlesnake.canberra.edu.au/cgi-bin/mailgraph.cgi/werewolf shows clearly the results of the changes between June and July (on the Month and Year graphs towards the bottom of the screen): many more messages are now being rejected rather than passed on to user accounts with [POSSIBLE SPAM] tags. Anecdotal evidence also suggests the amount of spam, even the number of messages marked as [POSSIBLE SPAM], has reduced since the increased measures were implemented.
Staff are asked to pass on spam and other unwanted email messages not marked as [POSSIBLE SPAM] that are still getting through to their in boxes to ICT Services for review, to establish what might be able to be done to reduce even further the amount of unwanted email reaching user accounts. A new Public Folder called SPAM for ICT should have appeared in your email client (under the Public Folders directory in your University account). Drag or save emails you believe to be examples of spam or other unwanted emails into this folder and they will be made available to ICT Services automatically. Contact the comedu helpdesk if you need assistance in transferring spam to this folder.
Forwarding suspect email to either ICT Services or the comedu helpdesk won’t help: forwarded emails may lose the data required by ICT Services to establish how it might have got through the filters in place.
The new arrangements in force may have unintended consequences for people outside the University sending legitimate email to University accounts. Otherwise legitimate email may be marked as [POSSIBLE SPAM] or even rejected without being delivered to the addressee. If you come across examples of this happening please contact the ICT Services helpdesk (x5500 or servicedesk@canberra.edu.au) to advise them and to seek advice on what needs to be done to overcome the issue.
If legitimate email is rejected the sender will receive an explanation of why the email was rejected by the University with instructions on what the sender (or their IT section or ISP) has to do to have their email delivered to the University recipient without being rejected in the future. While in some cases the original email may not be delivered to the intended recipient, in most cases the email will be delivered anyway while the problem is rectified at the sender’s end: the sender just keeps getting the message to have their email server configured properly to avoid the messages being rejected.
