Anyone sending bulk email can be flagged as a spammer. Bulk email is sending an email to a group of recipients. The more emails you send and the larger your recipient lists, the greater the risk of being flagged, but there is no such thing as a safe limit that you can stay under. Any bulk emails you send could potentially land you in trouble.

Everyone is coming down hard on email spam, from governments with anti-spam legislation like CASL, to Internet Service Providers (ISPs), who are doing more and more to detect and block bulk email.

ISPs, as well as companies that provide spam-filtering services, process a lot of email. This gives them the ability to collect large amounts of aggregate data with which to identify spam, and potentially blacklist the sender. Once you are blacklisted, it takes time and money to fix.

Services such as MailChimp, Constant Contact, and Campaign Monitor protect you from getting blacklisted. However, even when using these services, you must follow good email practices, because the industry looks at your "email reputation".

What is Email Reputation?

Your email reputation is how ISPs and anti-spam systems track and score the desirability of the bulk email your organization sends. If you have a good reputation, then there's a good chance your emails will end up in recipient inboxes. But if your reputation is low, then your emails are more likely to end up in spam folders or be blocked entirely.

Many factors can go into determining your email reputation, and every ISP does it differently. Common things they look at include:

• how many different people you send to.
• the total volume of email you send.
• whether you send to "spam trap" addresses - these are made-up addresses to which no emails should ever go.
• what percentage of emails you send, end up bouncing.
• how much user engagement your emails generate. If people delete your emails unopened, that's bad.
• how many recipients mark your emails as spam.
• how many recipients click "unsubscribe".

How can I protect my Email Reputation?

1. You want to keep your email lists clean. This means removing bounce back addresses from your email lists, and correcting typos. Repeatedly sending emails to addresses that bounce can really hurt your email reputation, as it's the mark of an indiscriminate spammer.
2. Follow CASL rules.
3. Be mindful of what you send and how often, people don't want to be bombarded. Even if they consent to email, they may still indicate to their ISP that your emails are "spam".

If you have a bad email reputation, third party email services may drop you as well.

How does the Exware AMS help?

• The Exware AMS has built-in CASL rules.
• The Exware AMS filters out repeated bounce backs until fixed by admin
• The Exware AMS integrates with third party email services so your domain/IP doesn't get blacklisted

In summary, organizations used to get away with anything when sending out email blasts. However, the industry and government legislation has changed that, and it's probably only going to get tougher.

I read a great article on web content writing tips

The key tip was write for "scanners". The article points out that only 16% of people read web pages word-for-word. Most people just scan.

When people scan a page, the four things they notice most are:

• Headings / headlines
• Sub-headings
• Image captions
• Lists of bullet points

These are things you should pay special attention to. In particular:

• Headings and sub-headings should focus on your key points.
• Captions on images should connect back to your main talking points.
• Bullet points are a good replacement for lengthy sentences and paragraphs. They should be short and concise.

These methods can help get your ideas across quickly, and perhaps entice people to read a little more.

A writer's most important tool is the delete key, so shorten your text and make your copy easy to read:

• Use short sentences and paragraphs
• Skip unnecessary words
• Avoid repetition
• Avoid jargon
• Avoid the passive tense
• Address your readers directly, using the word you

In a nutshell, write in plain English and keep it simple – visitors don't want to have to work to understand what you're trying to say.

Many organizations want to track detailed statistics about how their users consume their content, such as:

• who read the bulk email or newsletter we just sent out?
• did webinar attendees actually watch the full webinar video?
• how many people have read a PDF document?
• how much time do visitors spend on our website?

Many web service organizations will provide engagement stats that attempt to satisfy this desire to look over users' shoulders and keep track of what they are doing. But you should treat these numbers with a bit of skepticism.

Generally speaking, you cannot look over your users' s shoulders to determine exactly what they are doing. If your users have decided that they don't want to be spied on, then it would be a privacy violation for you to do so, assuming you even had that capability. (And, realistically, you don't have that capability.)

Most engagement stats use simple tricks to guess what the user is doing. They are not actually monitoring the user. Instead they are looking at your web server's traffic stats to see what content is delivered to the user's computer. To track individual users, the URLs that are used to request that content might be tagged with personalized tracking codes.

So you can look at your web stats to see that a video was accessed, and if you are using tracking codes, you can even infer who it was accessed by (assuming that user did not share the link with someone else). Your web stats can report exactly how much data was sent back, and from that you can infer whether that adds up to the complete video or not. But none of that means the user actually watched the video. Video players will preload (buffer) their content, so the fact that your web server (or video service) delivered the full video doesn't mean the video was actually played, or that it wasn't paused or closed before it got to the end. Because things like pausing happen on the user's personal computer, and not on your web server, they are much harder to track, require more invasive spyware tricks to monitor on the user, and are unreliable even with all that extra effort. (There are many popular browser plugins that block tracking software.)

Monitoring who reads your emails is similarly problematic. As with videos, there is no way to tell that an email was actually read. Because email is not on your website, you cannot even say if it was delivered. But there is a trick you can do to determine if an email was opened. This is done by embedding an image with a tracking code into the email. When that image is downloaded from your web server, you can detect that tracking code, and guess that the email was displayed somewhere. But even in that ideal case, that doesn't tell you if the user actually looked at the email, or were just whipping through their inbox, deleting unwanted messages. Most email programs also provide easy ways to disable automatic image loading, since it can also result in slow performance and unwanted data charges on mobile devices. Without image loading, your tracker simply won't work, and your open stats are not going to be reliable. Either way, many emails that show as opened were not read, and many that show as unopened were read.

Analytics packages like Google Analytics are pretty good for tracking your website usage. It won't track anyone who has disabled Javascript for your website, but that is normally a very small number of visitors, so the stats are still fairly reliable. Once you want to start tracking views of things like PDF documents, however, they don't work. This is simply because Google Analytics can only track web page usage, and PDF documents are not web pages. To get a measure of how popular your PDF is, you have to consult your web server stats again. This will tell you how many hits the PDF got, and how much data was downloaded in total, and even how many unique visitors viewed it. But treat these numbers with caution. Many of those visitors will be bots who are snooping through your website. If you have multiple visitors from a single company accessing the PDF, they may all look like a single visitor to your web logs. And some users may hit the PDF once and save it to their computer for further consultation, while others may leave the PDF on your website and hit it over and over again as they consult it repeatedly. Ultimately, your web stats cannot tell you how people are using the document.

Many web analytics packages like to report how much time visitors spent at your website. Again, these are just wild guesses, based on tracking codes, cookies, or click patterns. Even if the user doesn't block cookies, it is very difficult to say how long someone is at your site. How long should an analytics package report that someone is on your site, if your site is left open in a background tab all day long? Who is more engaged with your website, someone who visits the same page three times in one hour, or someone who opens the same page in a tab once but leaves it there all week? There is no clear answer, and analytics tools can only make guesses based on their own assumptions.

Once you start trying to gather detailed engagement stats to see what individual users are doing, there are additional privacy concerns that come into play. Gathering data about specific users may impact your privacy policy, as well fall under privacy regulations like PIPA, PIPEDA, and the GDPR. Given the legal burden of this data gathering, and the questionable accuracy of these statistics, you should consider how important they are to your operations before investing much effort in collecting and analyzing them.

Designing websites to work for visitors with disabilities is a complex subject, as there are many different disabilities that must be taken into consideration, each with its own requirements. There is no magic bullet that works for all disabilities.

Consider the seemingly simple task of embedding a video into your site, which you might not otherwise think twice about. Now ask yourself:

• Will a blind person be able to play this video? Is the audio track alone sufficient to convey the important information, or will you need to provide a written description of the visual content for them?
• Will a deaf person be able to watch this video? Are you providing a sign language alternative, or subtitles? Do the subtitles have sufficient contrast against different backgrounds in the video? Are subtitles sufficient to communicate all of the audio information, or should a separate transcription be provided?
• Does the video contain any bright flashing that might be problematic for viewers with epilepsy?
• Does the video have adequate keyboard controls to manage playback, volume, and subtitles?

WCAG (Web Content Accessibility Guidelines) defines the various considerations you should take into account when building your website content. Exware's software is designed to make it easy for you to build accessible websites that adhere to WCAG and other industry standards. But as the video example above shows, you are ultimately in control of your own content. The software platform you use will not magically make your content accessible, and you can break compliance if you are not diligent.

WCAG compliance is not a simple yes/no thing. It is an extremely complicated standard, there are different levels of compliance, and at the highest level of compliance (AAA) it may not even be possible to satisfy all requirements for some types of content. There are many aspects (e.g. accessibility for the blind, for the deaf, for different types of visual impairment, for the motor impaired, for epileptics, etc.). Rather than asking "are we WCAG compliant?", one should start by asking "how accessible are we?" and "which types of disabilities could have trouble using our website?"

Designing a site to work for all types of disabilities is a hard thing to do as that means you must take many different design compromises into consideration. For example:

• Visual content like images and videos need to have alternatives available. Sites that have visually engaging designs may use images and videos for design impact. Are those pieces of visual flair real content? Are they relevant to visitors who experience your website in a non-visual way? How does your visually impactful design translate to a non-visual browsing experience?
• Multimedia elements like video and audio are particularly problematic for some types of visitors. Such content may need to be completely reproduced in alternatives forms such as transcripts, or with sign language translations.
• Organizations often distribute information in document form, such as PDFs or other downloadable files. Since these are not web-specific content, they fall outside of WCAG, and may have their own accessibility issues. This is especially true for documents that are primarily visual in nature, such as brochures, posters, or presentation slides.
• Be careful about delivering content through animations, popups, flyouts, carousels, delayed loads, or other visual effects. Visual effects simply don't translate to non-visual methods of accessing your website. If done incorrectly, that content might be completely inaccessible for some readers. If these special effects affect your navigation (for example, drop-down or dynamic menus) it may prevent visitors from even reaching their destination. You should not only consider the effect on navigation for visually-impaired viewers, but also motor-impaired visitors who can see your web pages and special effects just fine, but may struggle to guide their mouse cursor through your popups and drop-downs.
• Be careful about using font sizes, styles, and colours to convey meaning, as those are all visual alterations that have no corresponding effect in text-to-speech readers. Readers with visual impairments may zoom your text to make it more legible, which will change all of your designer's font size choices. Make sure your design will tolerate such text zooming without breaking. Avoid text styles like bold and italic, which are purely visual, and use semantic equivalents like strong and em (emphasis), which give non-visual browsers some clues how to treat the information. Do not use headings for visual emphasis; declaring a piece of text as a heading will convey completely different information to a non-visual browser. And make sure your use of colour does not adversely affect the ability of colour-blind or visually impaired readers to see your text. Avoid low-contrast colour choices, especially between text and background colours. And make sure your links stand out for people with colour blindness issues, such as by keeping them underlined.

Designing for broad accessibility can put a lot of restrictions on how you design your site and deliver information to your visitors. Many graphic designers do not want to pay this price, because they are by nature visual designers, and broadly accessible designs can come across as comparatively plain (think about government websites, for instance). Many organizations concur, because they want to make an impact on site visitors—which usually means a visual impact. Because of this, you may have to accept some degree of accessibility imperfection if you are set on those visual effects. But with a small amount of care and attention, you can ensure that the imperfections do not break your website for disabled visitors, and that they are still able to access the critical content that they came to find.

SSL - What it Does

Website SSL provides a more secure way to interact with a website. With an SSL site, the URL starts with https instead of http - the "s" stands for "secure". SSL improves security in two ways: authentication and encryption.

• Authentication ensures that the domain being displayed in your browser's address bar is indeed the website you are seeing. This prevents users being victimized by a variety of hacking techniques designed to trick them into entering private information to a website that is not what it appears to be. SSL is not a cure-all, as there are many ways hackers and con-artists can trick people, but it does prevent some of the more insidious methods, such as DNS highjacking and man-in-the-middle attacks.
• Encryption prevents potential eavesdropping, which is especially important if you are accessing the internet over WIFI. Without encryption, your logins, passwords, and other sensitive information could be obtained by anyone able to intercept or listen in on your network traffic.

SSL - Why It's Become So Important

It's the need for encryption that has driven the adoption of SSL in recent years. Increasingly, browsers warn users whenever information is about to be entered on a website that is not using SSL. If you want users to trust your website and feel at ease, SSL has become a must-have.

Another huge motivator for encryption is the increased use of mobile computing. The ease and convenience of WIFI means it is also much easier for somebody nearby to listen in on your network traffic. The need for website SSL was made all the greater in October 2017 when it was discovered that WIFI's built-in security standard, WPA2, is highly vulnerable to attack, affording little protection against eavesdropping.

SSL - What are the Options?

SSL certificates are traditionally issued by a commercial certificate issuer, with prices ranging from tens to hundreds of dollars per year. In 2016, a new system for issuing free automated certs was created by Let's Encrypt, using a protocol called ACME. Commercial SSL certs are typically good for one or two years. Free ACME certs are good for at most 90 days but are renewed automatically.

So if there are expensive SSL certs, and cheaper certs, and very cheap certs, and even free certs, what's the difference?

The good news is that when it comes to encryption, there is no difference. All SSL certificates regardless of cost., support the same enterprise-level 2048-bit data encryption. And as we've seen, encryption is the main issue.

One way SSL certificates can differ is the level of website authentication they provide. The most basic level is domain validation (DV). This means that the domain on the cert matches the domain of the website, so if the browser address bar says https://www.somesite.com then you really are at www.somesite.com. All SSL certs provide this. For the vast majority of websites, this is all you really need.

Commercial SSL certificates can, at additional cost, provide organization validation (OV), and there's an even fancier version of this called extended validation (EV). While DV authenticates the domain, OV and EV also authenticates the legal business name of the organization, providing assurance that the people running the website really are who they claim to be.

With an OV cert, users can inspect the certificate in their browser and see the name of the organization, although most people won't know how to do that. With the even more expensive EV cert, the organization name appears in the browser's address bar in green, making it completely obvious. EV certs are what you normally see with banks and other financial institutions where trust is most important. Twitter currently uses an EV cert, but Facebook and Google don't bother, and just have OV certs. If your domain is widely recognized, then an EV cert doesn't add much.

There are a several other distinguishing features of SSL certificates:

Commercial SSL certificates provide liability protection, covering losses due to a flaw in the certificate. It's like insurance for the cert. For a basic GoDaddy cert, losses up to $100,000 are covered. Free certs do not have this at all, while more expensive certs typically cover higher amounts. It's debatable how useful this is.

Another consideration is reliability. SSL works because each browser - Chrome, Firefox, IE/Edge, Safari, etc - is programmed to trust the various certificate issuers. However if an issuer fails to exercise acceptable levels of security and diligence, they can have this trust revoked at the discretion of the browser makers. This could render invalid some or all of the SSL certificates that they've issued. While such occurences are rare, major websites typically use the more established and reputable issuers, which also tend to be more expensive.

Prestige and reputation can be a factor. Users who are very discriminating and technical may look at the issuer and level of a certificate, and use that to judge the trustworthiness and credibility of a website. A free or bargain-basement cert might be looked down upon.

For organizations wanting SSL on more than one domain, then a multi-domain SAN cert is an option. These support up to five different domains. Prices fluctuate, but if you have three or more domains, then a SAN cert is usually cheaper than three individual basic certs from a commercial issuer.