initial commitHEADmaster

10 files changed, 208 insertions, 0 deletions

diff --git a/postmarkapp/invoices/scott_gilbertson_invoice_01.odt b/postmarkapp/invoices/scott_gilbertson_invoice_01.odt
new file mode 100644
index 0000000..37640c2
--- /dev/null
+++ b/postmarkapp/invoices/scott_gilbertson_invoice_01.odt
diff --git a/postmarkapp/invoices/scott_gilbertson_invoice_01.pdf b/postmarkapp/invoices/scott_gilbertson_invoice_01.pdf
new file mode 100644
index 0000000..39bc4b7
--- /dev/null
+++ b/postmarkapp/invoices/scott_gilbertson_invoice_01.pdf
diff --git a/postmarkapp/invoices/scott_gilbertson_invoice_02.odt b/postmarkapp/invoices/scott_gilbertson_invoice_02.odt
new file mode 100644
index 0000000..b8d4215
--- /dev/null
+++ b/postmarkapp/invoices/scott_gilbertson_invoice_02.odt
diff --git a/postmarkapp/invoices/scott_gilbertson_invoice_02.pdf b/postmarkapp/invoices/scott_gilbertson_invoice_02.pdf
new file mode 100644
index 0000000..7a856a5
--- /dev/null
+++ b/postmarkapp/invoices/scott_gilbertson_invoice_02.pdf
diff --git a/postmarkapp/mailbrush.txt b/postmarkapp/mailbrush.txt
new file mode 100644
index 0000000..0e1c558
--- /dev/null
+++ b/postmarkapp/mailbrush.txt
@@ -0,0 +1,80 @@
+Many apps these days require installing some bit of code. Even small snippets of code are much easier to read and understand when they're properly syntax-highlighted. Most existing libraries for syntax highlighting are huge combinations of CSS and JavaScript and don't work at all in most mail clients.
+
+That's why we created MailBrush. MailBrush lets you add syntax highlighting to code snippets so they can be used in your email templates. 
+
+Instead of plain snippets in your email templates that look like this:
+
+{
+  "key": "value",
+  "key2": "value 2"
+}
+
+Your snippets will now look like this:
+
+tk Image here
+
+MailBrush has syntax highlighting support for HTML, CSS and JavaScript snippets, as well as JSON, PHP, HTTP and Bash. It allows for full customization of highlighting colors and styles so you can customize your highlighting to fit with the rest of your mail templates. Once you run MailBrush on your code the resulting HTML snippet will work in all major email clients:
+
+* Desktop
+    - Apple Mail 8, 9, 10
+    - Outlook 2003, 2007, 2010, 2011, 2013, 2016
+    - Windows 10 Mail
+* Mobile
+    - Gmail App (Android)
+    - iPhones
+    - iPads
+* Web
+    - AOL
+    - Gmail
+    - Outlook.com
+    - Yahoo
+
+Convinced? Okay, let's set up MailBrush and start generating some HTML. The first step is to install Node.js. The easiest way to get Node is to [grab the installer](https://nodejs.org/en/download/) from the Node.js site. That will work for both OS X and Windows. If you're on Linux you can also install via the Node download page, though you may be better off using your distro's package repository to install Node.
+
+Once you've got Node installed, installing MailBrush is simple. Just open up your terminal application and enter this command:
+
+npm install mailbrush --save
+
+That's it, you've got MailBrush installed. Now let's run it on some code.  There's some basic Node boilerplate code we need to write to make everything work, so here's a snippet you can use to get started:
+
+const mailbrush = require('mailbrush');
+
+// Specify options
+const options = {
+  language: 'json',
+  cssOptions: {
+    backgroundColor: 'pink'
+  }
+};
+
+// The code snippet you want to beautify
+const snippet = `{
+   "key": "value",
+   "key2": "value 2"
+}`
+
+mailbrush.convert(snippet, options, (html) => {
+  // Returns HTML with inlined CSS for email client compatibility
+  console.log(html);
+});
+
+Save that snippet in a file named app.js (or whatever you'd like to call it) and then you can run it with this command:
+
+node app.js
+
+In this case that would output this code:
+
+lxf@maya:~$ node app.js                  
+<table cellpadding="0" cellspacing="0" style="background: white;"><tr><td style="background: white; color: #000; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px; padding: 10px 15px;"><pre style="-moz-tab-size: 2; -ms-hyphens: none; -o-tab-size: 2; -webkit-hyphens: none; color: #000; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px; hyphens: none; line-height: 1.5; overflow: auto; tab-size: 2; text-align: left; white-space: pre; word-break: break-all; word-spacing: normal; word-wrap: normal;"><span style="color: #999; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">{</span>                
+   <span style="color: #905; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">"key"</span><span style="color: #a67f59; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">:</span> <span style="color: #690; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">"value"</span><span style="color: #999; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">,</span>                                                                                                                                                                                                           
+   <span style="color: #905; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">"key2"</span><span style="color: #a67f59; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">:</span> <span style="color: #690; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">"value 2"</span>                                                                                     
+<span style="color: #999; font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace; font-size: 13px;">}</span></pre></td></tr></table>                                                                                          
+
+That's all the HTML (and inline CSS) you need to put that snippet into your mail template. This code will be highlighted and will look good in all the supported mail clients listed above. 
+
+Now, to actually generate markup for your code you can change the script above. The `options` section is where you can change colors, fonts and highlighting. See the [MailBrush Github page](https://github.com/wildbit/mailbrush) for a full list of options. 
+
+The other two things you'll want to change is the language variable, which can be `markup`, `php`, `javascript`, `css`, `http`, or `bash`. Finally you'll want to change the `snippet` section to the actual code you want highlighted.
+
+And that's all there is to it. Happy highlighting!
+ 
diff --git a/postmarkapp/monitoring-email-2.txt b/postmarkapp/monitoring-email-2.txt
new file mode 100644
index 0000000..d2894c1
--- /dev/null
+++ b/postmarkapp/monitoring-email-2.txt
@@ -0,0 +1,17 @@
+If you've ever spent any time in the dashboard of your email service provider (ESP), you've probably focused on the open or click rate of you email. Why aren't people opening your email? It's tempting to immediately start re-writing your emails, using stronger headlines perhaps, or maybe toning down your copy to sound less aggressive. 
+
+While those certainly may be problems, there is often a much simpler answer. A lot of issues with low open/click rates are really just delivery issues.  Your customers can’t open/click on an email they never receive. If you’re seeing unusually low open/click rates for your industry, it’s very possible that it’s caused by delivery issues.
+
+Instead of spending time and resources A/B testing subject lines or revamping the design of your CTA buttons, you might be better off making sure your emails are actually being received.
+
+In the last post we covered some ways to monitor common issues that might stop your email from being delivered. And here, by delivered we really mean accepted by your customer's mail server (or service). That's half the battle. Once it's on your customer's server though there's a quite a few ways to monitor how that server delivers that email to the customer. That is, monitoring the so-called last mile -- does it get delivered to the inbox, sent to spam or hung up by some filter the customer never gets to see.
+
+Unfortunately, deliverability is hard to measure directly because you can’t login directly to everyone’s mailbox to see if an email was delivered. Your ESP probably doesn't know. When it says an email was "delivered" it could well mean that it was delivered to the spam folder, or in the case of Gmail, the promotions folder. There are however, some services that can help you get a better idea of where your email is going.
+
+The two big services in this space are [250ok](https://250ok.com/) and [ReturnPath](https://returnpath.com/). Using these services can give you quantifiable data about your inbox delivery rate. In other words you don’t just trust your ESP that their delivery is great, measure and monitor it.
+
+Once you've got some mailbox delivery monitoring system set up, you can start looking at the data. The big question will likely be how much of your email is ending up in the spam folder and why. Now you know how much is ending up there -- the industry standard is somewhere around 20 percent, depending on who you ask, though we think you should aim for much lower than that -- the question becomes, how do you fix it?
+
+Before you start hiring copy writers and running textual analysis on your keywords, consider that it might be something much lower level, like the quality of your ESP. Now that you have the tools to monitor delivery it's well worth your time to start comparing services. Just like you'd A/B test headlines, it's worth the time and effort to A/B test ESPs.
+
+We've already showcased a few examples of how monitoring delivery rates can help you migrate to a better ESP. One is Childcare.co.uk, which helps connects parents and childcare providers and tutors. When childcare.co.uk switched from Amazon SES to Postmark, they saw their open rates [go up 11 percent](https://postmarkapp.com/customers/childcare-co-uk). That's a huge win, but it's one you can only make if you're monitoring where your mail ends up.k
diff --git a/postmarkapp/monitoring-email.txt b/postmarkapp/monitoring-email.txt
new file mode 100644
index 0000000..ca2287b
--- /dev/null
+++ b/postmarkapp/monitoring-email.txt
@@ -0,0 +1,31 @@
+We usually take email delivery for granted. You hit send and assume the recipient will get it. That's usually a good assumption for personal email, but when you move beyond single emails delivery gets decidedly less certain.
+
+Fortunately you don't have to sit around just wondering whether your business' emails are being delivered. The internet is awash in helpful tools and techniques for monitoring email delivery. One of the keys though is to move beyond depending on your email service provider (ESP). ESPs can monitor delivery for you and, in many cases, even tell you what, if anything, is going wrong. However ESPs can't monitor everything about your system and may not always be able to diagnose your delivery problems.
+
+To help you start looking here are a few services you can use to track and measure delivery rates and diagnose potential problems.
+
+The first thing to keep in mind with email problems is Occam's razor -- your delivery problems often have a very simple cause and solution. It often won't be what many people assume, that the largely inscrutable spam filtering processes of ISPs or Google is out to get them.
+
+The problem is often much simpler than that. Even if it is an ISP out to get you, make sure you've eliminated the other possibilities first. Always start with the simple.
+
+### Monitor DNS records
+
+DNS records? Yes, DNS. It's so simple and so obvious we often forget how important it is. When you’re working at a company using several services, possibly several dozen domains, redirects and other possibly complicated configurations, it’s possible, even likely that the correct DNS configuration can get screwed up when someone makes an update. If you're not monitoring the DNS end of your delivery system you're going to end up with emails failing to be delivered. It's a simple problem with a simple fix, but one you won't know about if you aren't actively looking.
+
+
+### Monitor Blacklists 
+
+Starting with the very simple, make sure that your domains and IPs (or your ESP's IPs) haven't ended up on a spam blacklist. There are dozens of services out there that will monitor this for you. With hundreds of blacklists out there to keep track of you'll probably want to pay for a decent service that regular scans all public lists for any mention of your IPs and domains.
+
+### Track Delivery Time with MailHandler 
+
+Once you know your DNS is set up correctly and that you're not on any blacklists the next place to look is delivery speed. How long does it take from the time you hit send to the time that email ends up in your customer's mailbox? You're probably familiar with this problem from the other side -- nothing is more frustrating than that password reset form that claims it just emailed you but you know there's nothing in your inbox. That's a problem with delivery speed.
+
+To help you track and monitor delivery speed, Postmark built [MailHandler](https://github.com/wildbit/MailHandler), a set of tools you can use to send and retrieve emails and at the same time get details on how long these operations took. MailHandler is available as a Ruby gem and can send email through the Postmark API or by standard SMTP protocol. More importantly it also allows checking email delivery by IMAP protocol. 
+
+Using MailHandler you can begin to find and fix any delays in your delivery system
+
+### Success! Delivered. Or Not.
+
+Once you've got a good system set up for monitoring your sending system and you know your emails are being sent in a timely manner it's time to move on to the last mile so to speak -- the customer's inbox. When we say an email is "delivered" what we really mean is that was accepted by your customer's mail server (or service). Whether or not it was then placed in your customer's inbox is an entirely different problem that we'll tackle in the next installment.
+
diff --git a/postmarkapp/separating-transactional-bulk.txt b/postmarkapp/separating-transactional-bulk.txt
new file mode 100644
index 0000000..9d275e2
--- /dev/null
+++ b/postmarkapp/separating-transactional-bulk.txt
@@ -0,0 +1,22 @@
+You've probably been told to keep your transactional emails separate from your bulk emails, but what does that mean and why should you listen to this advice?
+
+Transactional emails are emails that your customer triggers -- a welcome email after a customer signs up, an alert email a customer has set up in your app, an invoice email and a comment notification all qualify as transactional email. There are others as well, the exact nature of transactional email you send will vary according to the type of app you run. 
+
+A bulk email is an email that is sent to more than one person that contains the exact same content and is not triggered by an event. A bulk email would be anything a customer did not specifically trigger, for example a weekly newsletter, a marketing email or an announcement about your site's recent updates. Currently, Postmark does not send bulk emails like these.
+
+To understand why Postmark doesn't send bulk emails, let's go back to that advice you may have heard -- why keep these two types of email separate? In a nutshell: keeping your important transactional emails -- the ones your customers are expecting -- separate makes them much more likely to land in the customer's inbox.  
+
+The reputation of the IP address, domain and email address all play a role in getting your email into your customer's inbox rather than their spam folder, or, in the case of Google, one of the inbox sub-categories like "Promotional". Email providers know that customers want and expect transactional emails, but it's not always easy for them to tell what's transactional and what's better classified as promotional. 
+
+Using separate domains or emails addresses for each kind of mail makes it much more likely that your important transactional email will to get to your customers.
+
+If you use the same servers and email address to send both bulk and transactional email filtering systems like Gmail's will likely classify it all as bulk email. That's why Gmail officially suggests that "if you send both promotional mail and transactional mail relating to your organization, we recommend separating mail by purpose as much as possible." Given the staggering number of Gmail users out there, adhering to this advice makes good business sense. 
+
+Since lost or even delayed transactional emails will result in support requests, like the familiar, "I tried to reset my password, but I never got a response from you", and more work for your organization. Then there's the potential lost customer trust. Searching through your spam folder for a legitimate email is never fun, don't send your customers into their spam folders when there's an easy way to avoid it -- keep them separated.
+
+So how to do you separate your mail? And what does “separate” mean? It means making sure your bulk emails comes from one source and your transactional from another, separating IP addresses, domains and possibly email addresses as well. These days reputation is increasingly shifting to domains because IPs are disposable. 
+
+For example you might send your bulk email from promo.yourdomain.com and your transactional email from trx.yourdomain.com. You could even use entirely different domains, for instance, mypromodomain.com and mydomain.com. Or you might be able to get by with just using promo@yourdmain.com for bulk and welcome@yourdomain.com.
+
+For us this isn't just a theory. Postmark sees the best inbox rates and delivery times in the industry because we only send transactional emails. That means our IPs have great reputations. We police them better than the other providers who are a bit more lax about it since they send bulk mail as well and rely on dedicated IPs when customers run into delivery issues on shared IPs. We know all this because a significant number of our customers are “refugees” from the other providers. They ran into delivery problems sending both bulk and transactional from a single source and came to us to make sure their transactional emails get where they need to be -- in their customer's inbox.
+
diff --git a/postmarkapp/separating-transactional-bulkv2.txt b/postmarkapp/separating-transactional-bulkv2.txt
new file mode 100644
index 0000000..9d275e2
--- /dev/null
+++ b/postmarkapp/separating-transactional-bulkv2.txt
@@ -0,0 +1,22 @@
+You've probably been told to keep your transactional emails separate from your bulk emails, but what does that mean and why should you listen to this advice?
+
+Transactional emails are emails that your customer triggers -- a welcome email after a customer signs up, an alert email a customer has set up in your app, an invoice email and a comment notification all qualify as transactional email. There are others as well, the exact nature of transactional email you send will vary according to the type of app you run. 
+
+A bulk email is an email that is sent to more than one person that contains the exact same content and is not triggered by an event. A bulk email would be anything a customer did not specifically trigger, for example a weekly newsletter, a marketing email or an announcement about your site's recent updates. Currently, Postmark does not send bulk emails like these.
+
+To understand why Postmark doesn't send bulk emails, let's go back to that advice you may have heard -- why keep these two types of email separate? In a nutshell: keeping your important transactional emails -- the ones your customers are expecting -- separate makes them much more likely to land in the customer's inbox.  
+
+The reputation of the IP address, domain and email address all play a role in getting your email into your customer's inbox rather than their spam folder, or, in the case of Google, one of the inbox sub-categories like "Promotional". Email providers know that customers want and expect transactional emails, but it's not always easy for them to tell what's transactional and what's better classified as promotional. 
+
+Using separate domains or emails addresses for each kind of mail makes it much more likely that your important transactional email will to get to your customers.
+
+If you use the same servers and email address to send both bulk and transactional email filtering systems like Gmail's will likely classify it all as bulk email. That's why Gmail officially suggests that "if you send both promotional mail and transactional mail relating to your organization, we recommend separating mail by purpose as much as possible." Given the staggering number of Gmail users out there, adhering to this advice makes good business sense. 
+
+Since lost or even delayed transactional emails will result in support requests, like the familiar, "I tried to reset my password, but I never got a response from you", and more work for your organization. Then there's the potential lost customer trust. Searching through your spam folder for a legitimate email is never fun, don't send your customers into their spam folders when there's an easy way to avoid it -- keep them separated.
+
+So how to do you separate your mail? And what does “separate” mean? It means making sure your bulk emails comes from one source and your transactional from another, separating IP addresses, domains and possibly email addresses as well. These days reputation is increasingly shifting to domains because IPs are disposable. 
+
+For example you might send your bulk email from promo.yourdomain.com and your transactional email from trx.yourdomain.com. You could even use entirely different domains, for instance, mypromodomain.com and mydomain.com. Or you might be able to get by with just using promo@yourdmain.com for bulk and welcome@yourdomain.com.
+
+For us this isn't just a theory. Postmark sees the best inbox rates and delivery times in the industry because we only send transactional emails. That means our IPs have great reputations. We police them better than the other providers who are a bit more lax about it since they send bulk mail as well and rely on dedicated IPs when customers run into delivery issues on shared IPs. We know all this because a significant number of our customers are “refugees” from the other providers. They ran into delivery problems sending both bulk and transactional from a single source and came to us to make sure their transactional emails get where they need to be -- in their customer's inbox.
+
diff --git a/postmarkapp/tools-techniques-delivery.txt b/postmarkapp/tools-techniques-delivery.txt
new file mode 100644
index 0000000..174c20c
--- /dev/null
+++ b/postmarkapp/tools-techniques-delivery.txt
@@ -0,0 +1,36 @@
+
+Tools and techniques for monitoring delivery
+
+
+
+
+*Using Detailed Logs for Troubleshooting* The big idea here is to create a version of our Troubleshooting guide that’s more Postmark-specific. In general, our guides are service-agnostic, but there’s a lot of powerful tools in Postmark that can make troubleshooting easier. We’d want to draw attention to the guide, but then this blog posts should focus specifically on where to find the solutions to these problems within Postmark.
+
+*What are the standard problems when it comes to delivery?* Understanding these helps understand the layers of troubleshooting. i.e.  Don’t start researching the most unlikely problem.  - Filtering (I.e. Technically “delivered” but to spam, promotions tab, etc.) - Bounces (I.e. Typos or mail boxes that no longer exist.) - Over-aggressive systems-level filters. (I.e. Overaggressive corporate firewalls)
+
+*Postmark Logs* - Events - Processed, Delivered, Bounced, Opened, Clicked - Content - Reviewing the full content of an email often exposes content that may have triggered spam filters
+
+*Troubleshooting steps*
+- What can you look into from your end?
+  - Was the email sent? (Sometimes people expect an email when one
+shouldn’t have been sent or hasn’t been sent.)
+  - How long has it ben? (Sometimes, delays happen. Either with ESP issues,
+receiving mail server issues, or something else entirely.)
+  - Was it “delivered” (really “accepted by the mail server” is a better
+phrase. Delivery doesn’t imply that it was passed to the inbox.)
+  - Did it go to spam or a promotional tab?
+  - Was there anything in the content that seems likely to trigger a spam
+filter? (Sometimes, there’s incredibly unlikely things like phone numbers
+or addresses that trigger the filters, but that’s less likely, so we
+investigate that later.) Postmark’s spam check tool is often handy here.
+  - Were their attachments? Files like docx and other attack vectors are
+often blocked by default from uknown sources.
+  - Verify authentication (SPF, DKIM, DMARC)
+  - If all else fails, check Google Postmark tools
+- What can the recipient look into from their end if you don’t see any
+obvious problems?
+  - Have them check their spam folder and promotional tabs if relevant
+  - Have the recipient reach out to their IT department with the delivery
+details to have them investigate.
+  - If relevant, have the recipient ask their IT department to whitelist
+the address, domain, or IPs depending on how their firewall works.