Email Address Recommendations

We strongly recommend against using individual's email addresses in code, in this document we recommend some alternatives.

There are maintainability and security risks involved with sending application-specific information to an individual's email address. Individual's email addresses get recycled and deactivated, and sensitive data may end up being delivered to an unintended recipient.

Monitored Addresses

Rather than having an email sent to an individual, sending it to a group mailbox or mailing list allows the recipients to be changed without needing to update the code.  There are three common ways to setup a group email:

Active Directory Group

Establishing and using an Active Directory (AD) mailing list. Mail sent to an AD mailing list is delivered to each of the group's members.  Example: ACT-MiddlewareIDM@ad.ucsd.edu

Pros:

• AD groups are already administered.  New developers are added and departing developers are removed as a normal course of business.
• Owner of the group can self-administer the group.

Cons:

• The list requires maintenance
• It is often not practical to setup new AD groups if an existing one doesn't meet the need
• Adding recipients also grants them additional privilege which are tied to the AD group
• Because this method still delivers the email content to an individual's mailbox, the security and audit risks are present

Recommended format: Department-GroupName@ad.ucsd.edu

Mailing Lists

Establishing and using a custom mailing list on UCSD's mailing list service. Mail sent to a UCSD mailing list is delivered to each of the list's members. Example: middlewareAlert-l@ucsd.edu

Pros:

• Mailing lists can easily be custom made for each requirement
• Developers can self administer the mailing list with multiple list administrators
• Creating new lists is simple and quick

Cons:

• The list requires maintenance
• Non-immediate delivery. Can take a few minutes for delivery.
• Because this method still delivers the email content to an individual's mailbox, the security and audit risks are present

Recommended format: descriptive-name-l@ucsd.edu

Service Account Email Addresses

The most professional looking of all solutions is to register an address and mailbox with the postmaster. Example: eBill@ucsd.edu

Pros:

• Easy to remember
• Clear intent
• Professional
• Emails don't end up in an individual's mailbox

Cons:

• Administration must be done through the postmaster
• Interested parties must have the credential to access this mailbox
• It is a yet another mailbox to log into
• Reserved for more general lists (e.g. eBill@ucsd.edu is ok, ebill-DBErrors@ucsd.edu is likely not)

Recommended format: ServiceOrGroup@ucsd.edu

Unmonitored Addresses

There are times that an email address is required, but nothing should ever be sent to it.  The most common case is the "from" or "reply to" field of generated emails. In this case an email should have a "from", but recipients should not reply to it.

No Reply Address

Anything sent to noreply@ucsd.edu is dropped. Example: noreply@ucsd.edu

Pros:

• Simple
• Most people know what a noreply address is.

Cons:

• Undescriptive, if used as "from" noreply does not indicate who the message was from.

Blackhole

Anything sent to @blackhole.ucsd.edu is treated like noreply and is dropped. Example: ebill@blackhole.ucsd.edu

Pros:

• Descriptive.  Users will know "who" sent the email.

Cons:

• Long & possibly confusing.

Support and Informational Email Addresses

In the case where an application displays a contact address for feedback, questions, or concerns, the recommendation is to use the email address of the first-line support or a link to a standard feedback form. An example is "For more information contact eBillHelp@ucsd.edu".

ACT Help Desk

In many cases the ACT Help Desk is the first line of support for ACT applications. In addition, using the standard application decorators will inherently include the Feedback link to the appropriate first line of support.