Customize Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorized as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customized advertisements based on the pages you visited previously and to analyze the effectiveness of the ad campaigns.

No cookies to display.

Categories
Articles

Using role-based e-mail addresses

An interesting query arrived about when to advertise role-based, rather than individual, e-mail addresses. Do role-based ones feel too impersonal, for example, because senders don’t know who they are dealing with?

I’ve been recommending the benefits of role-based e-mail addresses, such as service@jisc.ac.uk for a long time. From a legal point of view they avoid the question “can we get access to X’s mailbox while she’s away?”, which may well raise tricky questions under interception and human rights laws. If messages are sent to a role-based address then, even if they are stored in an individual’s mailbox, it’s easy to get a computer to extract those particular messages if someone else needs to deal with the request. It seems to me pretty clear that for those messages, this isn’t interception as the mail is still going to the “intended recipient” (the people performing the role). And I’d expect that to be what the sender expects to happen, too.

[I’ve also heard reports that there’s a psychological benefit: that team members are less upset by spam received via a role-based address than sent direct to an individual one]

So when might you advertise an individual address, such as my.name@example.ac.uk? Presumably when the arguments in favour of role-based ones don’t apply. So that’s for messages that shouldn’t be accessed by anyone else, even when the addressee is on leave or has left the organisation. Here we’re looking at situations where it’s more important that the message be dealt with by a specific individual than that it be dealt with on a particular timescale, or at all. Indeed I’d argue that the original concern – that senders don’t know who will they are dealing with – actually applies more strongly to this case. If you’ve advertised an individual’s address, knowing that there are circumstances in which the message will actually be read by someone else, then it seems to me that the sender really could say that they have been misled.

Which leads me to a possible rule-of-thumb: what should happen to e-mails when the individual leaves? If the answer is “handled by another member of the team”, then use a role-based address. If, however, the answer is “bounced, with a ‘no such user’ message” (or perhaps forwarded to the user’s new location) then use an individual one.

By Andrew Cormack

I'm Chief Regulatory Advisor at Jisc, responsible for keeping an eye out for places where our ideas, services and products might raise regulatory issues. My aim is to fix either the product or service, or the regulation, before there's a painful bump!

Leave a Reply

Your email address will not be published. Required fields are marked *