Email Infrastructure: Phase 1

Overview of Phase 1

Phase 1 configuration changes include:

  • Target web-based use cases for transition to Google SMTP
  • Convert tx.ncsu.edu from an implicit to an explicit alias
  • Begin process of converting unity.ncsu.edu from an implicit to an explicit alias
  • Turn on DKIM for messages originating from Gmail

In addition, OIT staff will be working on coding and development changes to support this and future phases, focusing on:

  • Improved Mail Manager tools
  • Solution to CRON-based emails (primarily RHEL boxes)
  • Proxy servers
    • Used by devices on private VLAN that can’t reach internet

Phase 1 begins July 1, 2017.

Targeted Services & Devices

Last year, the CITD and campus IT staff provided OIT with information on processes or devices being used to send email. After reviewing the information provided, we have identified several common use cases that will be impacted by the upcoming infrastructure changes.

Below, we have listed targeted services & devices that will be impacted by the changes made in Phase 1, or that must be addressed before OIT can proceed to Phase 2. This information was presented to Campus Web Developers in May 2017.

For SMTP connection details visit Google SMTP Settings.

Web Apps

For websites running WordPress: See Configuring WordPress.

For websites running Drupal: use the SMTP Authentication Support module

For other PHP web apps: use the Swift Mailer package configured to send authenticated SMTP email via Google.

For ColdFusion apps: ColdFusion 8.0 or above is required. Adobe provides documentation on configuring cfmail, including SMTP authentication. The cfmail tag only does username/password authentication.

Web Servers

OIT recommends that in most situations, each app or website being hosted on a web server be responsible for sending their own mail. One side effect of authenticated SMTP is that all mail is sent from the authenticated account or an approved sender on the authenticated account. By requiring each application or website to be responsible for sending their own mail, it allows each entity to define their own from address as well as appropriate reply address path.

In situations where an app or site cannot manage their own email sending, or to handle operational email needs from a web server; a server administrator will need to configure the default sending mechanism. For *nix boxes this is most often Sendmail or Postfix.

Create Authentication File
  1. Create the directory to house the auth file 
    mkdir -m 700 /etc/mail/authinfo
cd /etc/mail/authinfo
  2. Create the auth file with the following content. File can be named anything. Replace the email below with your NC State generic account address. Please note that in the password example you need to keep ‘P:’ as it is not a part of the actual password. 
    AuthInfo: “U:root” “I:generic-account@ncsu.edu" “P:YOUR PASSWORD”
  3. Create a hash map of the auth info where gmail-auth is the name of the auth file
    4. makemap hash gmail-auth < gmail-auth
Configure Sendmail
  1. Place the lines below into your /etc/mail/sendmail.mc configuration file right above first “MAILER” definition line. Do not put this info at the top of your config file! 
    define(`confCON_EXPENSIVE',`TRUE')dnl
define(`SMART_HOST', `[smtp.gmail.com]')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl
define(`ESMTP_MAILER_ARGS', `TCP $h 587')dnl
define(`confAUTH_OPTIONS', `A p')dnl
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
FEATURE(`authinfo', `hash -o /etc/mail/authinfo/gmail-auth.db')dnl
  2. Rebuild Sendmail’s configuration 
    make -C /etc/mail
  3. Reload Sendmail service 
    /etc/init.d/sendmail reload

Cloud Services

Any cloud-based or hosted services, need to also be properly configured if they send mail as an @ncsu.edu address. You’ll need to consult with your particular service provider for specific details on configuring authenticated SMTP.

If you need assistance working with your service provider, please contact us.

Implicit and explicit aliases

We will be converting all existing Domain Aliases into Secondary Domains.

A Domain Alias is a mail domain that acts like an alternate name for ncsu.edu. This means that for each Domain Alias, every user@ncsu.edu address also has a user@<Domain Alias> address implicitly (automatically) created for them.

By contrast, a Secondary Domain must have every email address explicitly (manually) listed.

Our current Domain Aliases are:

  • @tx.ncsu.edu
  • @eos.ncsu.edu
  • @unity.ncsu.edu

The GST plans to transition @tx.ncsu.edu and @eos.ncsu.edu to Secondary Domains, and eliminate the @unity.ncsu.edu domain entirely. We will define the list of @tx.ncsu.edu and @eos.ncsu.edu address that should continue to deliver explicitly in Google and then convert the domain from a Domain Alias to a Secondary Domain.  Once that change occurs, no address outside the lists will continue to deliver for that domain.

In Phase 1, we will focus on @tx.ncsu.edu and we will begin the process of whittling down @unity.ncsu.edu aliases.

DKIM for messages originating from Gmail

We will be implementing DKIM for the @ncsu.edu domain for any mail originating from Google including email sent via the web or SMTP interfaces. Timing and specifics will be communicated via Sysnews.