How the Site Does Email

The context of this page is about email as it relates to the web site. Assume for the discussion that the domain name is example.com unless otherwise noted.

The email issue for the site covers

1. The email the site sends to users.
2. The email received by the site from users.
3. Bulk email sent by the site.
4. Notifications sent to individual users based on events and preferences.
5. Setup email client for users with addresses in example.com domain.

Email From the Site

In the category of non-bulk email sent by the site, this covers scenarios like:

1. Password Resets
2. Direct email from an Administrator to a User
3. TBD?

Password Resets

It is preferable that the site is configured to use automation to help a user reset their password. This is the way.

The exception is in the case-by-case basis where the user has lost access to the email address that was used to register the account with the site. There are already Administrative policies in place to deal with that.

The nominal path is that users who have access to the email account they used to register on the site will be able to self-repair their forgotten password to the site.

Direct Manual Email

It would be preferred that any direct email with a registered user of the site is done with an official site email account. The rationale is that we want to establish a paper-trail with our communication with users. It protects them. It protects the owner, heirs and assigns of the site.

On the other hand, by using personal email accounts to reach out to registered members is an issue best left up to the individuals involved. Why it might be a sticky issue is that the registered user's email address is technically part of their Personal Information and by sending email from a personal address (the Admin) to a registered user, the registered user's email address is now in the paper-trail of the personal account of the Admin.

See the point above about Protect them/ Protect us.

TBD - Egress

I'm not aware of any other email sent by the site to registered users that is manually sent. If so, we need to document it.

Incoming Email to the Site

We will prefer that incoming email to the Site is sent to one or more official email aliases maintained by the Site.

For instance, suppose there are two Administrators: Alice the Administrator and Bob the Moderator. We would prefer that the Administrator is reached at some alias like [email protected] (where example.com is the domain of the site). We would prefer that the Moderator is reached at some alias like [email protected].

Of course we expect that there are multiple administrators and multiple moderators. So, those aliases would map to a set of actual user email addresses. The question is -- which addresses are the terminal addresses used in aliases? The site prefers to use site-controlled terminal addresses for aliases.

This means, in the example used that [email protected] is an email address controlled by example.com. [email protected] likewise is setup the same way. We have a second administrator [email protected] and a second moderator [email protected]. So the alias mapping would look like:

Alias	Email Addresses of recipients
[email protected]	[email protected], [email protected]
[email protected]	[email protected], [email protected]

The aliases for group-wise scenarios are subject to the choices made by the administrators. This is a mapping to figure decide.

The practice of handling incoming mail to aliases should include some guideline that when the recipient (the terminal address) replies to the registered user, the alias is CC'd. See catch-all guidance regarding protection.

Bulk Email

It might have been easier to think more fondly of a time when bulk-email was appropriate.

It doesn't seem to have the same degree of appreciation as it used to. Frankly, sites that send Bulk Email are setting themselves up for a long list of troubling problems. There are far more subtle ways to get a domain banned from having their future email being accepted. Once on the Ban List, it's not so easy to get removed. Sending bulk unsolicited email is a sure way to get on those lists.

The other troubling problem with bulk email is the headache of bad addresses. Bounces, replies, CC/Bcc storms are a nightmare situation.

The best angle to take is not to send Bulk Email. The web site is there for a reason. Social media is there for a reason. Use the systems that are meant for massive emission of message data. Email isn't it, anymore. Even if it was, which I don't believe it was really best suited.

The rise of email lists is a testament to the work-arounds system administrators set to deal with bulk-email.

The bottom line is that this site is strongly advised to not use bulk email.

Notification Style Email

The site software can send notifications for myriad events. The site software is configured to suppress or allow those notifications. Each user also has some flexibility in controlling what kind of notifications they receive.

The advice is to configure the software of the web site to elevate the importance of notifications that are helpful to the security of the registered user's account on the site -- odd login attempts from new devices, password resets, things like that.

What is probably not desired is heavy notifications for all sorts of minor events on the site like a post being liked, or followed.

There are far too many ways to be fed information these days, so the advice of the site is to take the attitude that let the user decide what they want -- let them opt-in wherever possible.

The sticky point is the address used to automatically send these notifications. It should be an alias like [email protected]. And preferably an alias/address that doesn't need to be monitored. In fact, the configuration should be such that email sent by [email protected] is from an unmonitored address.

Email Client Setup

The site uses a mixture of dovecot and postfix to control the email system.

The site configuration defines aliases and terminal addresses.

The SSL Certification is a self-signed certification. The self-signed SSL certification has a drawback that some major email sites (Gmail, etc.) do not accept self-signed certifications. This means, if the staff member uses Gmail (for example) and adds an account like [email protected] the Gmail server will reject it because the SSL certification is self-signed.

The option to work around this is either:

A. Get the SSL certification signed by a CA (Certificate Authority) B. Don't support Gmail/etc. systems

The "A" choice is preferred. But in the mean time, before a SSL certification signed by a CA is obtained, there is a work-around to use any other Email client that can ignore the self-signed SSL certification.

The Mozilla Project Thunderbird Email Client is one such option for staff members with official email addresses to access the email they are responsible for.

The details have been worked out for configuring the site to do SSL with Postfix and Dovecot.

TBD Post the config files to the repo

TBD Post the steps to configure Thunderbird Email Client.