Detailed information on Administrative bulk email sending

Tips and tricks for bulk email sending, Cautionary steps and information to use before for sending bulk mail. 

Detailed Information

1. Notes on Administrative bulk email

Many offices around the University system have a need to send bulk e-mail for a number of purposes. This can be billing notifications, financial aid awards, notices of deadlines, etc.  In this note, We are trying to gather notes on how to make sure that this mail is delivered quickly, reliably and with the least impact on our mail servers and other users of these servers.

• Do not use gmail to send bulk mail (see above boxed information)
• Use our bulk mail queue

Normally outgoing mail is submitted to mail.maine.edu (for individual mail) or smarthost.maine.edu (for mail servers). We have a queue called bulkmail.maine.edu for sending bulk mail that allows bulk mail to be sent at any time without affecting other mail. Bulk mail should NEVER be sent via mail.maine.edu.

2. Use authenticated SMTP

If your mail is getting flagged as spam, you can try using authenticated SMTP to connect to our bulk mail queue.  We can apply some headers to the mail that make it less likely to be flagged as spam.  To do this:

• You need a userid with the "Authenticated SMTP Access".  This authorization can be turned on by senior support staff.  Note that it may take more than 10 minutes for this authorization to take effect.
• The connection to the mail server must use encryption.  This may be port 25 with STARTTLS or port 465 with TLS/SSL.
• The authentication mechanism needs to be either "plain" or "login"
• Use just the userid by itself, do not include the @maine.edu 
• The mail relay host name to use is bulkmail.maine.edu

3. Send outside of normal business hours

If the bulk mailing is not time critical (emergencies, weather closings, etc.) and is not using an efficient distribution mechanism (like Listserv), please try to send outside of normal business hours so as not to clog up the mail queues. Before 7AM and after 5PM on weekdays would be preferred.

4. RFC Compliance

The documents defining standards within the internet are, for historical reasons, called RFCs (Requests For Comments). Any mail sent must conform to these standards if they are to be reliably delivered. Most mail systems are somewhat liberal in what they will accept, but with the increase in spam, they are becoming much more strict in requiring mail stick to the letter of the standards if it is to be accepted or not flagged as spam. Common violations are:

• Sending mail from an address that cannot receive mail. The address in the SMTP envelope MUST be a valid e-mail address that will accept mail since it is where bounce mail is sent. More and more mail servers verify this and reject mail that fails the test. In short, you cannot just make up an address to send mail from.
• Invalid date/time headers. There is a very strict format for these and they need to be accurate.
• Missing/invalid message IDs.
• Bad MIME encoding

5. Try not to look like spam

Almost every mail system includes spam scanners that look at mail files to determine if mail is spam. Some common things to watch out for:

• Don't send From: the same address you are sending it To:
• A reply-to different from the From: may make it more likely to be flagged.
• Make sure you have a subject line. It should be mixed case. Avoid $ and ! in the subject.
• Avoid lots of upper case text in the body of your e-mail.
• Send plain text if possible.
• Avoid lots of images in mail.
• If you include links in your e-mail, it is best not to make them click-able, but ask them to cut and paste.
• If you make links click-able, do not use IP addresses, they will be flagged as possible phishing. If the link text is similar to a web address, the link must match or it will be flagged as phishing. That is if the text of the link says www.maine.edu, the underlying link better point to www.maine.edu.
• Do not use URL shorteners (forms.gle, bit.ly, t.co, tinyurl.com for example), due to their heavy use by phishers and spammers to hide the actual URL they are very likely to cause mail to be flagged.
• Don't include “web bugs” (one pixel images with unique names used to determine if e-mail is read) these will be flagged.

6. If generic mail, send one copy

Much administrative mail amounts to sending the identical e-mail to a list of users. If at all possible, use mailing list software like Listserv or Google Groups to send ONE mail file to your list of addresses. If sent this way, it can be delivered perhaps hundreds of times faster, does not load down mail systems and can be sent without problems at any time of day. Since the mail is sent once (or just a few times) it is less likely to trigger bulk mail detection systems (like DCC, Pyzor, etc) and potentially get flagged as spam.

7. Avoid use of mailing lists from data brokers

Many of these lists are scraped from web sites, social media and the like and so are not opt-in nor people we have a relationship with and so will be considered spam.   In addition, many black lists seed web sites with spam trap addresses to catch these practices.   One email to a spam trap email address can result in our mail relays being blacklisted and we will block mail from anyone using such a list in order to protect our mail servers.

Risk

Anti-spam measures we employ that may affect administrative bulk email

1. Greet Pause

This inserts a 5 second pause between the time a connection is made to our mail relays and when they respond with the initial greeting.   Some spam sending programs don't wait for the greeting and start sending right away (so-called spam cannons).   When this is happens, our mail servers close the connection avoiding a significant amount of spam.     Most mail servers open a connection and send all the mail they have queued through the single connection so mail is not significantly delayed.   However, we have seen software being used by some departments that opens a new connection for each mail file sent rather than the better practice of opening a single connection.   This can lead to it taking a very long time to send a large batch of email.   If the program cannot be fixed or replaced, the connection rate limit can be overridden by adding the NM tag mail.greetpause to the host entry of the machine used to send the email.  A value of 0 will turn off the greet pause.

2. Client Connection Rate limit

This limits the number of connections per minute from a given IP address.  This protects our mail servers from being swamped by huge numbers of incoming connections and can slow down the incoming rate of spam emails.   We have exceptions in place for our own mail relays and for those we receive a lot of email from (Google, Microsoft, Qualtrics, and etc.).   Bulk mail programs that open a new connection for each email rather than sending all mail down a single connection may hit this limit.   Some especially poorly written email programs may not be able to handle the return codes from the mail server that say, try again later, and fail.   If these programs cannot be replaced or reconfigured,   the connection rate limit can be overridden by adding the NM tag mail.clientrate to the host sending the email.  The value of the tag is in connections per minute.

Environment

- Web based email