When to include a physical address

One of the requirements to be CAN-SPAM compliant is to include a physical address within every promotional email that is sent. If your company hires a third party to send email on your behalf, your physical address should be clearly visible within the message when the message is selling your products and services. There is a stipulation that if your message is transactional or a relationship message, then it does not need to adhere to the CAN-SPAM requirements by including your physical address or unsubscribe link.
Examples of transactional mail would be welcome emails, password resets, auto-responders, shipment notifications, or account alerts.  While you and I may know that these emails aren’t required to include this information most users would not know.
street-signsThe CAN-SPAM Act has been in effect going on 12 years and recipients look for unsubscribe links and physical addresses within the messages. Emails that are missing this bit of information leads the recipient to believing the message is spam.  While including the physical address and unsubscribe link are not required for your transactional emails, it’s better to be safe than sorry and include them anyways.
The recipient may have recently received a series of marketing emails from you and when they receive a transactional mail message, they may want to adjust the frequency of the mail they are receiving. By not including an unsubscribe link and physical address, the user may resort to marking the message as spam.
When sending marketing and transactional emails, you want to adhere to the law and then take the user behavior and expectations into consideration. There is no harm in including your physical address in both your marketing emails and transactional emails.

Related Posts

Lavabit shuts down

Lavabit is a secure mail system. Today their CEO announced he was shutting down the service immediately.

Read More

The Physics of the Email Universe

We talk a lot about rules and best practices in email, but we’re mostly talking about “squishy” rules-of-thumb that are based on simplified models of how mail systems, spam filters, recipients, postmasters and blacklist operators behave. They’re the biology, ecology and sociology of the email ecosystem.
There’s another set of rules we tend to only mention in passing, if at all, though. They’re the steely, sharp-edged laws that control the email universe. They’re the RFCs that define how email works and make sure that mail systems written by hundreds of different people across the globe all work and all interoperate with each other.
Building a message from Zeros and Ones
RFC 5322 – Internet Message Format
This tells you everything you need to know about crafting a simple email, with a subject line, a sender, some recipients and a simple plain-text message. It’s also the foundation of all fancier emails. If you’re creating emails, this is where to start.
A little more than plain ASCII
RFC 2047 – MIME Part 3: Message Header Extensions for Non-ASCII Text
RFC 2047 is one small part of the MIME (Multipurpose Internet Mail Extensions) suite of protocols that allow you to include pictures and attachments and prettily formatted text and comic sans in your email. This part defines how you can put things other than the plainest of plain text in your subject lines or in the “friendly from” of your message. It’s what allows you to put Hiragana, or Cyrillic, or umlauts, or cedillas, or properly matched double quotes in your subject line. It also let’s you put hearts or smiley faces or other little pictograms there – but nothing this useful is going to be perfect.
RFC 2045 – MIME Part 1: Format of Internet Message Bodies
This shows how to send an image, or a plain text mail in a different character set, or an HTML mail. It doesn’t tell you how to send plain text and HTML, or to send HTML with embedded images, or a message with an attached document. For that you need…
Finally, Modern Email
RFC 2046 – MIME Part 2: Media Types
This builds on RFC 2045 to allow you to have many different chunks in a message – this is what you need if you want to send “proper” HTML mail with a plain text alternative, or if you want embedded images or attachments.
Getting From A To B
RFC 5321 – Simple Mail Transfer Protocol
A message isn’t much use unless you send it somewhere. RFC 5321 explains the mysteries of actually sending that message over the wire to the recipient. If you need to know about the different phases of a message delivery, what “4xx” and “5xx” actually mean, why there’s not really any such thing as a hard or soft bounce defined, just temporary or permanent failures, or anything else about actually sending mail or diagnosing mail delivery, this is your starting point.
The Rest Of The Iceberg
I’ve only touched on the very smallest tip of the email iceberg here. There’s much, much more – both in RFCs and ad-hoc non-RFC standards. If you’re interested in more, this is a decent place to start.

Read More

Amazon launching new email service WorkMail

Amazon is launching a new email service called Amazon WorkMail.  Amazon already offers a Simple Email Service (SES) that allows customers to send outbound-only emails and unlike SES, WorkMail will be a full feature email, calendaring, and client management product.  The new WorkMail mail service will compete with enterprise email solutions such as Microsoft Exchange Server.  WorkMail will support the Microsoft Exchange ActiveSync protocol, something that Google disabled with Gmail in early 2013, and will include Mobile Device Management and Active Directory Integration. The new service will also utilize Amazon’s AWS Key Management Service that allows the customer to create and control their own encryption keys used to encrypt their data on AWS.
Amazon WorkMail will also scan all incoming and outgoing email for spam, malware, and viruses, however, it’s not clear yet if they are going with a third-party solution or will be creating their own filtering system.

Read More