Tag Archives: Outlook

AWS Online Tech Talks – November 2017

Post Syndicated from Sara Rodas original https://aws.amazon.com/blogs/aws/aws-online-tech-talks-november-2017/

Leaves are crunching under my boots, Halloween is tomorrow, and pumpkin is having its annual moment in the sun – it’s fall everybody! And just in time to celebrate, we have whipped up a fresh batch of pumpkin spice Tech Talks. Grab your planner (Outlook calendar) and pencil these puppies in. This month we are covering re:Invent, serverless, and everything in between.

November 2017 – Schedule

Noted below are the upcoming scheduled live, online technical sessions being held during the month of November. Make sure to register ahead of time so you won’t miss out on these free talks conducted by AWS subject matter experts.

Webinars featured this month are:

Monday, November 6

Compute

9:00 – 9:40 AM PDT: Set it and Forget it: Auto Scaling Target Tracking Policies

Tuesday, November 7

Big Data

9:00 – 9:40 AM PDT: Real-time Application Monitoring with Amazon Kinesis and Amazon CloudWatch

Compute

10:30 – 11:10 AM PDT: Simplify Microsoft Windows Server Management with Amazon Lightsail

Mobile

12:00 – 12:40 PM PDT: Deep Dive on Amazon SES What’s New

Wednesday, November 8

Databases

10:30 – 11:10 AM PDT: Migrating Your Oracle Database to PostgreSQL

Compute

12:00 – 12:40 PM PDT: Run Your CI/CD Pipeline at Scale for a Fraction of the Cost

Thursday, November 9

Databases

10:30 – 11:10 AM PDT: Migrating Your Oracle Database to PostgreSQL

Containers

9:00 – 9:40 AM PDT: Managing Container Images with Amazon ECR

Big Data

12:00 – 12:40 PM PDT: Amazon Elasticsearch Service Security Deep Dive

Monday, November 13

re:Invent

10:30 – 11:10 AM PDT: AWS re:Invent 2017: Know Before You Go

5:00 – 5:40 PM PDT: AWS re:Invent 2017: Know Before You Go

Tuesday, November 14

AI

9:00 – 9:40 AM PDT: Sentiment Analysis Using Apache MXNet and Gluon

10:30 – 11:10 AM PDT: Bringing Characters to Life with Amazon Polly Text-to-Speech

IoT

12:00 – 12:40 PM PDT: Essential Capabilities of an IoT Cloud Platform

Enterprise

2:00 – 2:40 PM PDT: Everything you wanted to know about licensing Windows workloads on AWS, but were afraid to ask

Wednesday, November 15

Security & Identity

9:00 – 9:40 AM PDT: How to Integrate AWS Directory Service with Office365

Storage

10:30 – 11:10 AM PDT: Disaster Recovery Options with AWS

Hands on Lab

12:30 – 2:00 PM PDT: Hands on Lab: Windows Workloads

Thursday, November 16

Serverless

9:00 – 9:40 AM PDT: Building Serverless Websites with [email protected]

Hands on Lab

12:30 – 2:00 PM PDT: Hands on Lab: Deploy .NET Code to AWS from Visual Studio

– Sara

Top Ten Ways to Protect Yourself Against Phishing Attacks

Post Syndicated from Roderick Bauer original https://www.backblaze.com/blog/top-ten-ways-protect-phishing-attacks/

It’s hard to miss the increasing frequency of phishing attacks in the news. Earlier this year, a major phishing attack targeted Google Docs users, and attempted to compromise at least one million Google Docs accounts. Experts say the “phish” was convincing and sophisticated, and even people who thought they would never be fooled by a phishing attack were caught in its net.

What is phishing?

Phishing attacks use seemingly trustworthy but malicious emails and websites to obtain your personal account or banking information. The attacks are cunning and highly effective because they often appear to come from an organization or business you actually use. The scam comes into play by tricking you into visiting a website you believe belongs to the trustworthy organization, but in fact is under the control of the phisher attempting to extract your private information.

Phishing attacks are once again in the news due to a handful of high profile ransomware incidents. Ransomware invades a user’s computer, encrypts their data files, and demands payment to decrypt the files. Ransomware most often makes its way onto a user’s computer through a phishing exploit, which gives the ransomware access to the user’s computer.

The best strategy against phishing is to scrutinize every email and message you receive and never to get caught. Easier said than done—even smart people sometimes fall victim to a phishing attack. To minimize the damage in an event of a phishing attack, backing up your data is the best ultimate defense and should be part of your anti-phishing and overall anti-malware strategy.

How do you recognize a phishing attack?

A phishing attacker may send an email seemingly from a reputable credit card company or financial institution that requests account information, often suggesting that there is a problem with your account. When users respond with the requested information, attackers can use it to gain access to the accounts.

The image below is a mockup of how a phishing attempt might appear. In this example, courtesy of Wikipedia, the bank is fictional, but in a real attempt the sender would use an actual bank, perhaps even the bank where the targeted victim does business. The sender is attempting to trick the recipient into revealing confidential information by getting the victim to visit the phisher’s website. Note the misspelling of the words “received” and “discrepancy” as recieved and discrepency. Misspellings sometimes are indications of a phishing attack. Also note that although the URL of the bank’s webpage appears to be legitimate, the hyperlink would actually take you to the phisher’s webpage, which would be altogether different from the URL displayed in the message.

By Andrew Levine – en:Image:PhishingTrustedBank.png, Public Domain, https://commons.wikimedia.org/w/index.php?curid=549747

Top ten ways to protect yourself against phishing attacks

  1. Always think twice when presented with a link in any kind of email or message before you click on it. Ask yourself whether the sender would ask you to do what it is requesting. Most banks and reputable service providers won’t ask you to reveal your account information or password via email. If in doubt, don’t use the link in the message and instead open a new webpage and go directly to the known website of the organization. Sign in to the site in the normal manner to verify that the request is legitimate.
  2. A good precaution is to always hover over a link before clicking on it and observe the status line in your browser to verify that the link in the text and the destination link are in fact the same.
  3. Phishers are clever, and they’re getting better all the time, and you might be fooled by a simple ruse to make you think the link is one you recognize. Links can have hard-to-detect misspellings that would result in visiting a site very different than what you expected.
  4. Be wary even of emails and message from people you know. It’s very easy to spoof an email so it appears to come from someone you know, or to create a URL that appears to be legitimate, but isn’t.

For example, let’s say that you work for roughmedia.com and you get an email from Chuck in accounting ([email protected]) that has an attachment for you, perhaps a company form you need to fill out. You likely wouldn’t notice in the sender address that the phisher has replaced the “m” in media with an “r” and an “n” that look very much like an “m.” You think it’s good old Chuck in finance and it’s actually someone “phishing” for you to open the attachment and infect your computer. This type of attack is known as “spear phishing” because it’s targeted at a specific individual and is using social engineering—specifically familiarity with the sender—as part of the scheme to fool you into trusting the attachment. This technique is by far the most successful on the internet today. (This example is based on Gimlet Media’s Reply All Podcast Episode, “What Kind of Idiot Gets Phished?“)

  1. Use anti-malware software, but don’t rely on it to catch all attacks. Phishers change their approach often to keep ahead of the software attack detectors.
  2. If you are asked to enter any valuable information, only do so if you’re on a secure connection. Look for the “https” prefix before the site URL, indicating the site is employing SSL (Secure Socket Layer). If there is no “s” after “http,” it’s best not to enter any confidential information.
By Fabio Lanari – Internet1.jpg by Rock1997 modified., GFDL, https://commons.wikimedia.org/w/index.php?curid=20995390
  1. Avoid logging in to online banks and similar services via public Wi-Fi networks. Criminals can compromise open networks with man-in-the-middle attacks that capture your information or spoof website addresses over the connection and redirect you to a fake page they control.
  2. Email, instant messaging, and gaming social channels are all possible vehicles to deliver phishing attacks, so be vigilant!
  3. Lay the foundation for a good defense by choosing reputable tech vendors and service providers that respect your privacy and take steps to protect your data. At Backblaze, we have full-time security teams constantly looking for ways to improve our security.
  4. When it is available, always take advantage of multi-factor verification to protect your accounts. The standard categories used for authentication are 1) something you know (e.g. your username and password), 2) something you are (e.g. your fingerprint or retina pattern), and 3) something you have (e.g. an authenticator app on your smartphone). An account that allows only a single factor for authentication is more susceptible to hacking than one that supports multiple factors. Backblaze supports multi-factor authentication to protect customer accounts.

Be a good internet citizen, and help reduce phishing and other malware attacks by notifying the organization being impersonated in the phishing attempt, or by forwarding suspicious messages to the Federal Trade Commission at [email protected]. Some email clients and services, such as Microsoft Outlook and Google Gmail, give you the ability to easily report suspicious emails. Phishing emails misrepresenting Apple can be reported to [email protected].

Backing up your data is an important part of a strong defense against phishing and other malware

The best way to avoid becoming a victim is to be vigilant against suspicious messages and emails, but also to assume that no matter what you do, it is very possible that your system will be compromised. Even the most sophisticated and tech-savvy of us can be ensnared if we are tired, in a rush, or just unfamiliar with the latest methods hackers are using. Remember that hackers are working full-time on ways to fool us, so it’s very difficult to keep ahead of them.

The best defense is to make sure that any data that could compromised by hackers—basically all of the data that is reachable via your computer—is not your only copy. You do that by maintaining an active and reliable backup strategy.

Files that are backed up to cloud storage, such as with Backblaze, are not vulnerable to attacks on your local computer in the way that local files, attached drives, network drives, or sync services like Dropbox that have local directories on your computer are.

In the event that your computer is compromised and your files are lost or encrypted, you can recover your files if you have a cloud backup that is beyond the reach of attacks on your computer.

The post Top Ten Ways to Protect Yourself Against Phishing Attacks appeared first on Backblaze Blog | Cloud Storage & Cloud Backup.

Pollexy – Building a Special Needs Voice Assistant with Amazon Polly and Raspberry Pi

Post Syndicated from Ana Visneski original https://aws.amazon.com/blogs/aws/pollexy-building-a-special-needs-voice-assistant-with-amazon-polly-and-raspberry-pi/

April is Autism Awareness month and about 1 in 68 children in the U.S. have been identified with autism spectrum disorder (ASD) (CDC 2014). In this post from Troy Larson, a Sr. Devops Cloud Architect here at AWS, you get an introduction to a project he has been working on to help his son Calvin.

I have been asked how the minds at AWS come up with so many different ideas. Sometimes they come from a deeply personal place, where someone sees a way to help others. Pollexy is an amazing example of just that. Read about Pollexy and then watch the video here.

-Ana


Background

As a computer programming parent of a 16-year old non-verbal teenage boy with autism, I have been constantly searching over the years to find ways to use technology to make our lives together safer, happier and more comfortable. At the core of this challenge is the most basic of all human interaction—communication. While Calvin is able to respond to verbal instruction, he is not able to speak responsively. In his entire life, we’ve never had a conversation. He is able to be left alone in his room to play, but most every task or set of tasks requires a human to verbally prompt him along the way. Having other children and responsibilities in the home, at times the intensity of supervision can be negatively impactful on the home dynamic.

Genesis

When I saw the announcement of Amazon Polly and Amazon Lex at re:Invent last year, I immediately started churning on how we could leverage these technologies to assist Calvin. He responds well to human verbal prompts, but would he understand a digital voice? So one Saturday, I setup a Raspberry Pi in his room and closed his door and crouched around the corner with other family members so Calvin couldn’t see us. I connected to the Raspberry Pi and instructed Polly to speak in Joanna’s familiar pacific tone, “Calvin, it’s time to take a potty break. Go out of your bedroom and go to the bathroom.” In a few seconds, we heard his doorknob turn and I poked my head out of my hiding place. Calvin passed by, looking at me quizzically, then went into the bathroom as Joanna had instructed. We all looked at each other in amazement—he had listened and responded perfectly to the completely invisible voice of someone he’d never heard before. After discussing some ideas around this with co-workers, a colleague suggested I enter the IoT and AI Science Fair at our annual AWS Sales Kick-Off meeting. Less than two months after the Polly and Lex announcement and 3500 lines of code later, Pollexy—along with Calvin–debuted at the Science Fair.

Overview

Pollexy (“Polly” + “Lex”) is a Raspberry Pi and mobile-based special needs verbal assistant that lets caretakers schedule audio task prompts and messages both on a recurring schedule and/or on-demand. Caretakers can schedule regular medicine reminder messages or hourly bathroom break messages, for example, and at the same time use their Amazon Echo and mobile device to request a specific message be played immediately. Caretakers can even set it up so that the person needs to confirm that they’ve heard the message. For example, my son won’t pay attention to Pollexy unless Pollexy first asks him to “Push the blue button.” Pollexy will wait until he has pushed the button and then speak the actual message. Other people may be able to respond verbally using Lex, or not require a confirmation at all. Pollexy can be tailored to what works best.

And then most importantly—and most challenging—in a large house, how do we make sure the person is in the room where we play the message? What if we have a special needs adult living in an in-law suite? Are they in the living room or the kitchen? And what about multiple people? What if we have multiple people in different areas of the house, each of whom has a message? Let’s explore the basic elements and tie the pieces together.

Basic Elements of Pollexy

In the spirit of Amazon’s Leadership Principle “Invent and Simplify,” we want to minimize the complexity of the Pollexy architecture. We can break Pollexy down into three types of objects and three components, all of which work together in a way that’s easily explainable.

Object #1: Person

Pollexy can support any number of people. A person is a uniquely identifiable name. We can set basic preferences such as “requires confirmation” and most importantly, we can define a location schedule. This means that we can create an Outlook-like schedule that sets preferences where someone should be in the house.

Object #2: Location

A location is simply a uniquely identifiable location where a device is physically sitting. Based on the user’s location schedule, Pollexy will know which device to contact first, second, third, etc. We can also “mute” devices if needed (naptime, etc.)

Object #3: Message

Obviously, this is the actual message we want to play. Attached to each message is a person and a recurring schedule (only if it’s not a one-time message). We don’t store location with the message, because Pollexy figures out the person’s location when the message is ready to be delivered.

Component #1: Scheduler

Every message needs to be scheduled. This is a command-line tool where you basically say Tell “Calvin” that “you need to brush your teeth” every night at 8 p.m. This message is then stored in DynamoDB, waiting to be picked up by the queueing Lambda function.

Component #2: Queueing Engine

Every minute, a Lambda runs and checks the scheduler to see if there is a message or messages ready to be delivered. If a message is ready, it looks up the person’s location schedule and figures out where they are and then pushes the message or messages into an SQS queue for that location.

Component #3: Speaker Engine

Every minute on the Raspberry Pi device, the speaker engine spins up and checks the SQS for its location. If there are messages, then the speaker engine looks at the user’s preferences and initiates communication to convey the message. If the person doesn’t respond, the speaker engine will check if the person has a secondary location in their schedule and drop the message in the SQS Queue for that location. In the end, a message will either be delivered or eventually just timeout (if someone is out of the house for the day).

Respect and Freedom are the Keys

We often take our personal privacy and respect for granted, so imagine even for a special needs person, the lack of privacy and freedom around having a person constantly in your presence. This is exaggerated for those in the autism spectrum where invasion of personal space can escalate a sense of invasion, turning into anger and frustration. Pollexy becomes their own personal, gentle and never-flustered friend to coach to them along the way, giving them confidence, respect and the sense of privacy and freedom we all want to enjoy.

-Troy Larson

JavaWatch automated coffee replenishment system

Post Syndicated from Alex Bate original https://www.raspberrypi.org/blog/javawatch-automated-coffee-replenishment-system/

With the JavaWatch system from Terren Peterson, there’s (Raspberry Pi) ZERO reason for you ever to run out of coffee beans again!

By utilising many of the Amazon Web Services (AWS) available to budding developers, Terren was able to create a Pi Zero-powered image detection unit. Using the Raspberry Pi Camera Module to keep tabs on your coffee bean storage, it automatically orders a fresh batch of java when supplies are running low.

JavaWatch Sales Pitch

Introducing JavaWatch, the amazing device that monitors your coffee bean supply and refills from Amazon.com.

Coffee: quite possibly powering Pi Towers’ success

Here at Pi Towers, it’s safe to say that the vast majority of staff members run on high levels of caffeine. In fact, despite hitting ten million Pi boards sold last October, sending two Astro Pi units to space, documenting over 5,000 Code Clubs in the UK, and multiple other impressive achievements, the greatest accomplishment of the Pi Towers team is probably the acquisition of a new all-singing, all-dancing coffee machine for the kitchen. For, if nothing else, it has increased the constant flow of caffeine into the engineers…and that’s always a positive thing, right?

Here are some glamour shots of the beautiful beast:

Pi Towers coffee machine glamour shot
Pi Towers coffee machine glamour shot
Pi Towers coffee machine glamour shot

Anyway, back to JavaWatch

Terren uses the same technology that can be found in an Amazon Dash button, replacing the ‘button-press’ stimulus with image recognition to trigger a purchase request.

JavaWatch flow diagram

Going with the JavaWatch flow… 
Image from Terren’s hackster.io project page.

“The service was straightforward to get working,” Terren explains on his freeCodeCamp blog post. “The Raspberry Pi Camera Module captures and uploads photos at preset intervals to S3, the object-based storage service by AWS.”

The data is used to calculate the amount of coffee beans in stock. For example, the jar in the following image is registered at 73% full:

A jar which is almost full of coffee beans

It could also be 27% empty, depending on your general outlook on life.

A second photo, where the beans take up a mere 15% or so of the jar, registers no beans. As a result, JavaWatch orders more via a small website created specifically for the task, just like pressing a Dash button.

JavaWatch DRS Demo

Demonstration of DRS Capabilities with a project called JavaWatch. This orders coffee beans when the container runs empty.

Terren won second place in hackster.io’s Amazon DRS Developer Challenge for JavaWatch. If you are in need of regular and reliable caffeine infusions, you can find more information on the build, including Terren’s code, on his project page.

The post JavaWatch automated coffee replenishment system appeared first on Raspberry Pi.

Amazon Chime – Unified Communications Service

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/amazon-chime-unified-communications-service/

If your working day is anything like mine, you probably spend a lot of time communicating with your colleagues. Every day, I connect with and collaborate with people all over the world. Some of them are sitting in their office in front of their PCs; others are on the go and using their phones to connect and to communicate. We chat informally, we meet on regular schedules, we exchange documents and images, and we share our screens.

For many years, most “business productivity” tools have been anything but. Many of these tools support just one or two modes of communication or styles of collaboration and can end up getting in the way. Licensing and training costs and a lack of support for collaboration that crosses organizational boundaries don’t make things any better.

Time to change that…

Introducing Amazon Chime
Today I would like to tell you about Amazon Chime. This is a new unified communication service that is designed to make meetings easier and more efficient than ever before. Amazon Chime lets you start high-quality audio and video meetings with a click. Once you are in the meeting you can chat, share content, and share screens in a smooth experience that spans PC and Mac desktops, iOS devices, and Android devices.

Because Amazon Chime is a fully managed service, there’s no upfront investment, software deployment, or ongoing maintenance. Users simply download the Amazon Chime app and start using it within minutes.

Let’s take a quick look at some of the most important features of Amazon Chime:

On-Time Meetings – You no longer need to dial in to meetings. There’s no need to enter long meeting identifiers or equally long passwords. Instead, Amazon Chime will alert you when the meeting starts, and allow you to join (or to indicate that you are running behind) with a single click or tap.

Meeting Roster – Instead of endless “who just joined” queries, Amazon Chime provides a visual roster of attendees, late-comers, and those who skipped out entirely. It also provides broadly accessible mute controls in case another participant is typing or their dog is barking.

Broad AccessAmazon Chime was built for mobile use, with apps that run on PCs and mobile devices. Even better, Amazon Chime allows you to join a meeting from one device and then seamlessly switch to another.

Easy Sharing – Collaborating is a core competency for Amazon Chime. Meeting participants can share their screens as desired, with no need to ask for permission. Within Amazon Chime‘s chat rooms, participants can work together and create a shared history that is stored in encrypted fashion.

Clear CallsAmazon Chime delivers high quality noise-cancelled audio and crisp, clear HD video that works across all user devices and with most conference room video systems.

Amazon Chime in Action
Let’s run through the most important aspects of Amazon Chime, starting with the main screen:

I can click on Meetings and then schedule a meeting in my Outlook calendar or my Google calendar:

Outlook scheduling makes use of the Amazon Chime add-in; I was prompted to install it when I clicked on Schedule with Outlook. I simply set up an invite as usual:

Amazon Chime lets me know when the meeting is starting:

I simply click on Answer and choose my audio option:

And my meeting is under way. I can invite others, share my screen or any desired window, use my webcam, and so forth:

I have many options that I can change while the meeting is underway:

Amazon Chime also includes persistent, 1 to 1 chat and chat rooms. Here’s how I create a new chat room:

After I create it I can invite my fellow bloggers and we can have a long-term, ongoing conversation.

As usual, I have only shown you a few of the features! To get started, visit the Amazon Chime site and try it out for yourself.

Amazon Chime Editions
Amazon Chime is available in three editions:

  • Basic Edition is available at no charge. It allows you to attend meetings, make 1 to 1 video calls, and to use all Amazon Chime chat features.
  • Plus Edition costs $2.50 per user per month. It allows user management of entire email domains, supports 1 GB of message retention per user, and connects to Active Directory.
  • Pro Edition costs $15.00 per user per month. It allows hosting of meetings of up to 100 people.

Amazon Chime Pro is free to try for 30 days, with no credit card required. After 30 days, you can continue to use Amazon Chime Basic for free, for as long as you’d like, or you can purchase Amazon Chime Pro for $15.00 per user per month. There is no upfront commitment, and you can change or cancel your subscription at any time.

Available Now
Amazon Chime is available now and you can sign up to start using it today!

Jeff;

 

Using Pi to experience another’s reality

Post Syndicated from Alex Bate original https://www.raspberrypi.org/blog/using-pi-experience-anothers-reality/

Have you ever fancied being part of a real-life version of Being John Malkovich, without the danger of becoming trapped in a portal into the mind of an actor? This project helps you experience just that.

European telecoms operator Tele2 recently relaunched their phone and internet service with a particularly hefty data plan offering 100GB that customers can use across nine different devices, and they asked creative agency Your Majesty to market the new offering. The agency had a novel take on the brief:

In Sweden, a lot of discussion around connectivity tends to be negative, especially when it comes to controlling our exposure to media that can alter our outlook on our surroundings and the world. What if we made a campaign to show limitless connectivity in a way that changes our perspective?

Striving to alter that negative viewpoint, they didn’t focus on anything as simple as nine devices all working at once, but rather went in a very different direction.

Tele2: Settle For More – Case Film

Tele2 is a Swedish telecom company that provides phone and Internet services. They are re-launching in a big way to become the best data provider in the country and asked us to create a campaign to showcase a killer offer.

The final outcome was an immersive online experience, allowing viewers the chance to ‘step inside the minds’ of nine Swedish celebrities, including actor Joel Kinnaman and our favourite Queen of – ahem! – shoddy robots, Simone Giertz.

Users of the Pi-powered device

A custom backpack housed a 3D-printed rig to support a Raspberry Pi 3 for collection of sensor data, and a colour-grading box for footage recorded by a GoPro-equipped helmet.

Image of components

“Wait: did she just say ‘collection of sensor data’?” Yes. Yes, I did. Along with the video and audio streams from the on-board GoPro and microphone, the system collected data on heart rate, emotional state, and even sweat. Delicious.

screenshots from the device

The brain sensor data collected from the EEG then controls the colour of the footage as it’s relayed back to the audience: green for calm, yellow for happy, red for angry, and blue for sad. We can confirm that Simone’s screen turned a deep shade of purple on more than one occasion, and her heart rate actually shot up when she thought she had burned out some servos.

Videos from the various participants can be viewed at the Tele2 YouTube channel, including Joel, Simone, entrepreneur Cristina Stenbeck, and altitude instructor Anna Lundh.

Working with marketing agency Edelman Deportivo and digital studio Wolfmother Co., Your Majesty documented the impact of the campaign on Bēhance, so check it out.

The post Using Pi to experience another’s reality appeared first on Raspberry Pi.

Lamers: the problem with bounties

Post Syndicated from Robert Graham original http://blog.erratasec.com/2016/10/lamers-gtfo-please.html

In my last two posts, I pointed out that the anti-spam technique known as “DKIM” cryptographically verifies emails. This can be used to verify that some of the newsworthy emails are, indeed, correct and haven’t been doctored. I offer a 1 btc (one bitcoin, around ~$600 at current exchange rates) bounty if anybody can challenge this assertion.
Unfortunately, bounties attract lamers who think they deserve the bounty. 
This guy insists he wins the bounty because he can add spaces to the email, and add fields like “Cc:” that DKIM doesn’t check. Since DKIM ignores extra spaces and only checks important fields, these changes pass. The guy claims it’s “doctored” because technically, he has changed things, even though he hasn’t actually changed any of the important things (From, Date, Subject, and body content).
No. This doesn’t qualify for the bounty. It doesn’t call into question whether the Wikileaks emails say what they appear to say. It’s so obvious that people have already contacted me and passed on it, knowing it wouldn’t win the bounty. If I’d pay out this bounty for this lameness, one of the 10 people who came up with the idea before this lamer would get this bounty, not him. It’d probably go to this guy — who knows it’s lame, who isn’t seeking the bounty, but would get it anyway before the lamer above:
Let me get ahead of the lamers and point to more sophisticated stuff that also doesn’t count. The following DKIM verified email appears to say that Hillary admitting she eats kittens. This would be newsworthy if true, and a winner of this bounty if indeed it could trick people.
This is in fact also very lame. I mean, it’s damn convincing, but only to lamers. You can see my trick by looking at the email on pastebin (http://pastebin.com/wRsnz0Y6) and comparing it to the original (https://wikileaks.org/podesta-emails/emailid/2986).
The trick is that I’ve added extra From/Subject fields before the DKIM header, so DKIM doesn’t see them. DKIM only sees the fields after. It tricks other validation tools, such as this online validator. However, email readers (Thunderbird, Outlook, Apple Mail) see the first headers, and display something that DKIM hasn’t checked.

I’ve taken a screenshot of the raw email to show both From fields:

Since I don’t rely upon the “magic” of tools to verify DKIM, but look at the whole package, I’ll see the added From/Subject fields. Far from fooling anybody, such modifications will be smoking gun that somebody has attempted illicit modifications. Not just me, mostly anybody viewing the “raw source” that Wikileaks provides would instantly see shenanigans.
The Wikileaks emails can be verified with crypto, using DKIM. Anybody who can doctor an email in such a way that calls this into question, such that they could pass something incriminating through (“I eat kittens”), they win the full bounty. Any good attempts, with something interesting and innovative, wins partial bounty.
Lamers, though, are unwelcome.
BTW, the same is true for bug bounties. Bounties are becoming standard in the infosec industry, whereby companies give people money if they can show ways hackers might hack products. Paying bounties allows companies to fix products before they actually get hacked. Even the U.S. military offers bounties if you can show ways to hack their computers. Lamers are a pox on bug bounty systems — administrators must spend more time telling lamers to go away than they spend on dealing with real issues. No bounties rules are so tight that lamers can’t find a way to subvert the rules without finding anything that matches the intent.

Technology betrays everyone

Post Syndicated from Robert Graham original http://blog.erratasec.com/2016/05/technology-betrays-everyone.html

Kelly Jackson Higgins has a story about how I hacked her 10 years ago, by sniffing her email password via WiFi and displaying it on screen. It wasn’t her fault — it was technology’s fault. Sooner or later, it will betray you.

The same thing happened to me at CanSecWest around the year 2001, for pretty much exactly the same reasons. I think it was HD Moore who sniffed my email password. The thing is, I’m an expert, who writes tools that sniff these passwords, so it wasn’t like I was an innocent party here. Instead, simply opening my laptop with Outlook running the background was enough for it to automatically connect to WiFi, then connect to a POP3 server across the Internet. I thought I was in control of the evil technology — but this incident proved I wasn’t.

By 2006, though, major email services were now supporting email wholly across SSL, so that this would no longer happen — in theory. In practice, they still left the old non-encrypted ports open. Users could secure themselves, if they tried hard, but they usually weren’t secured.

Today, in 2016, the situation is much better. If you use Yahoo! Mail or GMail, you don’t even have the option to not encrypt — even if you wanted to. Unfortunately, many people are using old services that haven’t upgraded, like EarthLink or Network Solutions. These were popular services during the dot-com era 20 years ago, but haven’t evolved since. They spend enough to keep the lights on, but not enough to keep up with the times. Indeed, EarthLink doesn’t even allow for encryption even if you wanted it, as an earlier story this year showed.

My presentation in 2006 wasn’t about email passwords, but about all the other junk that leaks private information. Specifically, I discussed WiFi MAC addresses, and how they can be used to track mobile devices. Only in the last couple years have mobile phone vendors done something to change this. The latest version of iOS 9 will now randomize the MAC address, so that “they” can no longer easily track you by it.

The point of this post is this. If you are thinking “surely my tech won’t harm me in stupid ways”, you are wrong. It will. Even if it says on the box “100% secure”, it’s not secure. Indeed, those who promise the most often deliver the least. Those on the forefront of innovation (Apple, Google, and Facebook), but even they must be treated with a health dose of skepticism.

So what’s the answer? Paranoia and knowledge. First, never put too much faith in the tech. It’s not enough, for example, for encryption to be an option — you want encryption enforced so that unencrypted is not an option. Second, learn how things work. Learn why SSL works the way it does, why it’s POP3S and not POP3, and why “certificate warnings” are a thing. The more important security is to you, the more conservative your paranoia and the more extensive your knowledge should become.

Appendix: Early this year, the EFF (Electronic Freedom Foundation) had a chart of various chat applications and their features (end-to-end, open-source, etc.). On one hand, it was good information. On the other hand, it was bad, in that it still wasn’t enough for the non-knowledgeable to make a good decision. They could easily pick a chat app that had all the right features (green check-marks across the board), but still be one that could easily be defeated.

Likewise, recommendations to use “Tor” are perilous. Tor is indeed a good thing, but if you blindly trust it without understanding it, it will quickly betray you. If your adversary is the secret police of your country cracking down on dissidents, then you need to learn a lot more about how Tor works before you can trust it.

Notes: I’m sorta required to write this post, since I can’t let it go unremarked that the same thing happened to me — even though I know better.

Start Planning for AWS re:Invent 2016

Post Syndicated from Craig Liebendorfer original https://blogs.aws.amazon.com/security/post/Tx31S9L7QPFKF6O/Start-Planning-for-AWS-re-Invent-2016

AWS re:Invent 2016 will take place November 28–December 2, 2016, in Las Vegas, Nevada.  Start planning now to attend the world’s largest global cloud computing conference. We have designed re:Invent 2016 to give you increased opportunities to connect, collaborate, and learn about AWS solutions. This year, we are offering all-new mini-conferences on topics such as the Internet of Things (IoT), serverless computing, security, and containers. In addition, we are delivering more than 400 sessions (twice as many as 2015), and more hands-on labs, bootcamps, and opportunities for one-on-one engagements with AWS experts.

What to expect at AWS re:Invent 2016

  • A full additional day of content
  • 4 new mini-conferences
  • Multiple Hackathons and more GameDays
  • Reserved seating for breakout sessions
  • Quirky after-hours experiences, including a new re:Invent 5k run, and our 5th annual world famous re:Play party!
  • Flight discounts and other perks offered by Delta Air Lines, our preferred global airline

Full conference pass and registration information

The price of a full conference pass for AWS re:Invent 2016 is $1,599. Registration will open June 23, 2016. Mark your calendars now to be ready to purchase your re:Invent full conference pass starting June 23. 

Registration save the date:                      iCal    |    Google    |    Outlook

Start planning now

Start planning your trip now by visiting the AWS re:Invent website. You will find booking links for hotels, and a new Delta flight discount to make your travel planning easier. Book your flight and hotel now.

Stay connected

Join the conversation on Twitter with #reInvent and follow @AWSreInvent for news and updates.

We look forward to seeing you in November!

– Craig

PS: Interested in sponsorship opportunities at AWS re:Invent 2016? Reach out to us. 

Early Internet services considered harmful

Post Syndicated from Robert Graham original http://blog.erratasec.com/2016/02/early-internet-services-considered.html

This journalist, while writing a story on the #FBIvApple debate, got his email account hacked while on the airplane. Of course he did. His email account is with Earthlink, an early Internet services provider from the 1990s. Such early providers (AOL, Network Solutions, etc.) haven’t kept up with the times. If that’s still your email, there’s pretty much no way to secure it.Early Internet stuff wasn’t encrypted, because encryption was hard, and it was hard for bad guys to tap into wires to eavesdrop. Now, with open WiFi hotspots at Starbucks or on the airplane, it’s easy for hackers to eavesdrop on your network traffic. Simultaneously, encryption has become a lot easier. All new companies, those still fighting to acquire new customers, have thus upgraded their infrastructure to support encryption. Stagnant old companies, who are just milking their customers for profits, haven’t upgraded their infrastructure.You see this in the picture below. Earthlink supports older un-encrypted “POP3” (for fetching email from the server), but not the new encrypted POP3 over SSL. Conversely, GMail doesn’t support the older un-encrypted stuff (even if you wanted it to), but only the newer encrypted version.Thus, if you are a reporter using Earthlink, of course you’ll get hacked every time you fetch your email (from your phone, or using an app like Outlook on the laptop). I point this out because the story then includes some recommendations on how to protect yourself, and they are complete nonsense. The only recommendation here is to stop using Earthlink, and other ancient email providers. Open your settings for how you get email and check the “port” number. If it’s 110, stop using that email provider (unless STARTTLS is enabled). If it’s 995, you are likely okay.The more general lesson is that hacking doesn’t work like magic. The reporter’s email program was sending unencrypted passwords, and the solution is to stop doing that.Update: No, Earthlink doesn’t support STARTTLS either.

Early Internet services considered harmful

Post Syndicated from Robert Graham original http://blog.erratasec.com/2016/02/early-internet-services-considered.html

This journalist, while writing a story on the #FBIvApple debate, got his email account hacked while on the airplane. Of course he did. His email account is with Earthlink, an early Internet services provider from the 1990s. Such early providers (AOL, Network Solutions, etc.) haven’t kept up with the times. If that’s still your email, there’s pretty much no way to secure it.Early Internet stuff wasn’t encrypted, because encryption was hard, and it was hard for bad guys to tap into wires to eavesdrop. Now, with open WiFi hotspots at Starbucks or on the airplane, it’s easy for hackers to eavesdrop on your network traffic. Simultaneously, encryption has become a lot easier. All new companies, those still fighting to acquire new customers, have thus upgraded their infrastructure to support encryption. Stagnant old companies, who are just milking their customers for profits, haven’t upgraded their infrastructure.You see this in the picture below. Earthlink supports older un-encrypted “POP3” (for fetching email from the server), but not the new encrypted POP3 over SSL. Conversely, GMail doesn’t support the older un-encrypted stuff (even if you wanted it to), but only the newer encrypted version.Thus, if you are a reporter using Earthlink, of course you’ll get hacked every time you fetch your email (from your phone, or using an app like Outlook on the laptop). I point this out because the story then includes some recommendations on how to protect yourself, and they are complete nonsense. The only recommendation here is to stop using Earthlink, and other ancient email providers. Open your settings for how you get email and check the “port” number. If it’s 110, stop using that email provider (unless STARTTLS is enabled). If it’s 995, you are likely okay.The more general lesson is that hacking doesn’t work like magic. The reporter’s email program was sending unencrypted passwords, and the solution is to stop doing that.Update: No, Earthlink doesn’t support STARTTLS either.

Exercising Software Freedom in the Global Email System

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/09/15/email.html

[ This post
was cross-posted
on Conservancy’s blog
. ]

In this post, I discuss one example of how a choice for software freedom
can cause many strange problems that others will dismiss. My goal here is
to explain in gory detail how proprietary software biases in the computing
world continue to grow, notwithstanding Open Source ballyhoo.

Two decades ago, nearly every company, organization, entity, and
tech-minded individual ran their own email server. Generally speaking,
even back then, nearly all the software for both
MTAs and
MUAs were Free
Software0. MTA’s are the mail
transport agents — the complex software that moves email around from
one Internet domain to another. MUAs are the mail user agents, sometimes
called mail clients — the local programs with which users manipulate
their own email.

I’ve run my own MTA since around 1993: initially with sendmail, then with
exim for a while, and with Postfix since 1999 or so. Also, everywhere I’ve
worked throughout my entire career since 1995, I’ve either been in charge
of — or been the manager of the person in charge of — the MTA
installation for the organization where I worked. In all cases, that MTA
has always been Free Software, of course.

However, the world of email has changed drastically during that period.
The most notable change in the email world is the influx of massive amounts
of spam, which has been used as an excuse to implement another disturbing
change. Slowly but surely, email service — both the MTA and the MUA
— have been outsourced for most organizations. Specifically, either
(a) organizations run proprietary software on their own computers to deal
with email and/or (b) people pay a third-party to run proprietary and/or
trade-secret software on their behalf to handle the email services. Email,
generally speaking, isn’t handled by Free Software all that much
anymore.

This situation became acutely apparent to me this earlier this month when
Conservancy moved its email server. I had plenty of warning that the move
was needed1, and I’d set up
a test site on the new server. We sent and received some of our email for
months (mostly mailing list traffic) using that server configured with a
different domain (sf-conservancy.org). When the shut-off day came, I moved
sfconservancy.org’s email officially. All looked good: I had a current
Debian, with a new version of Postfix and Dovecot on a speedier host, and
with better spam protection settings in Postfix and better spam filtering
with a newer version of SpamAssassin. All was going great, thanks to all
those great Free Software projects — until the proprietary software
vendors threw a spanner in our works.

For reasons that we’ll never determine for
sure2, the IPv4
number that our new hosting provide gave us was already listed on many
spam blacklists.
I won’t debate the validity of various blacklists here, but the fact is, for
nearly every public-facing, pure-blacklist-only service, delisting is
straightforward, takes about 24 hours, and requires at most answering some
basic questions about your domain name and answering a captcha-like
challenge. These services, even though some are quite dubious, are not the
center of my complaint.

The real peril comes from third-party email hosting companies. These
companies have arbitrary, non-public blacklisting rules. More importantly,
they are not merely blacklist maintainers, they are MTA (and in some cases,
even MUA) providers who sell their proprietary and/or trade-secret hosted
solutions as a package to customers. Years ago, the idea of giving up that
much control of what happens to your own email would be considered
unbelievable. Today, it’s commonplace.

And herein lies the fact that is obvious to most software freedom
advocates but indiscernible by most email users. As a Free Software user,
with your own MTA on your own machine, your software only functions if
everyone else respects your right to run that software yourself.
Furthermore, if the people you want to email are fully removed from their
hosting service, they won’t realize nor understand that their hosting site
might block your emails. These companies have their customers fully
manipulated to oppose your software freedom. In other words, you can’t
appeal to those customers (the people you want to email), because you’re
likely the only person to ever raise this issue with them (i.e., unless
they know you very well, they’ll assume you’re crazy). You’re left begging
to the provider, whom you have no business relationship with, to
convince them that their customers want to hear from you. Your voice rings
out indecipherable from the spammers who want the same permission to attack
their customers.

The upshot for Conservancy? For days, Microsoft told all its customers
that Conservancy is a spammer; Microsoft did it so subtly that the
customers wouldn’t even believe it if we told them. Specifically, every
time I or one of my Conservancy colleagues emailed organizations using
Microsoft’s “Exchange Online”, “Office 365” or
similar products to host email for their
domain4, we got the following
response:

Sep 2 23:26:26 pine postfix/smtp[31888]: 27CD6E12B: to=, relay=example-org.mail.protection.outlook.com[207.46.163.215]:25, delay=5.6, delays=0.43/0/0.16/5, dsn=5.7.1, status=bounced (host example-org.mail.protection.outlook.com[207.46.163.215] said: 550 5.7.1 Service unavailable; Client host [162.242.171.33] blocked using FBLW15; To request removal from this list please forward this message to [email protected] (in reply to RCPT TO command))

Oh, you ask, did you forward your message to the specified address?
Of course I did; right away! I got back an email that said:

Hello ,

Thank you for your delisting request SRXNUMBERSID. Your ticket was
received on (Sep 01 2015 06:13 PM UTC) and will be responded to within 24
hours.

Once we passed the 24 hour mark with no response, I started looking around
for more information. I
also saw
a suggestion online
that calling is the only way to escalate one of
those tickets, so I phoned 800-865-9408 and gave V-2JECOD my ticket number
and she told that I could only raise these issues with the “Mail Flow
Team”. She put me on hold for them, and told me that I was number 2
in the queue for them so it should be a few minutes. I waited on hold for
just under six hours. I finally reached a helpful representative, who said
the ticket was the lowest level of escalation available (he hinted that it
would take weeks to resolve at that level, which is consistent with other
comments about this problem I’ve seen online). The fellow on the phone
agreed to escalate it to the highest priority available, and said within
four hours, Conservancy should be delisted. Thus, ultimately, I did
resolve these issues after about 72 hours. But, I’d spent about 15 hours
all-told researching various blacklists, email hosting companies, and their
procedures3, and that was after I’d
already carefully configured our MTA and DNS to be very RFC-compliant
(which is complicated and confusing, but absolutely essential to stay off
these blacklists once you’re off).

Admittedly, this sounds like a standard Kafkaesque experience with a large
company that almost everyone in post-modern society has experienced.
However, it’s different in one key way: I had to convince Microsoft to
allow me to communicate with their customers who are paying Microsoft for
proprietary and/or trade-secret software and services, ostensibly to
improve efficiency of their communications. Plus, since Microsoft, by the
nature of their so-called spam blocking, doesn’t inform their customers whom
they’ve blocked, I and my colleagues would have just sounded crazy if we’d
asked our contacts to call their provider instead. (I actually considered
this, and realized that we might negatively impact relationships with
professional contacts.)

These problems do reduce email software freedom by network effects.
Most people rely on third-party proprietary email software
from Google, Microsoft, Barracuda, or others. Therefore, most people,
don’t exercise any software freedom regarding email
services. Since exercising software freedom for email slowly becomes a
rarer and rarer (rather than norm it once was), society slowly but surely
pegs those who do exercise software freedom as
“random crazy people”.

There are a few companies who are seeking to do email hosting in a way
that respects your software freedom. The real test of such companies is if
someone technically minded can get the same software configured on their
own systems, and have it work the same way. Yet, in most cases, you go to
one of these companies’ Github pages and find a bunch of stuff pushed
public, but limited information on how to configure it so that it functions
the same way the hosted service does. RMS wrote years ago
that Free
Software cannot properly succeed without Free Documentation
, and in
many of these hosting cases: the hosting company is using fully
upstreamed Free Software, but has configured the software in a way that is
difficult to stumble upon by oneself. (For that reason, I’m committing to
writing up tutorials on how Conservancy configured our mail server, so at
least I’ll be part of the solution instead of part of the problem.)

BTW, as I dealt with all this, I couldn’t help but think
of John
Gilmore’s activism efforts regarding open mail relays
. While I don’t
agree with all of John’s positions on this, his fundamental position is
right: we must oppose companies who think they know better how we should
configure our email servers (or on which IP numbers we should run those
servers). I’d add a corollary that there’s a serious threat to software
freedom, at least with regard to email software, if we continue to allow such
top-down control of the once beautifully decentralized email system.

The future of software freedom depends on issues like this. Imagine
someone who has just learned that they can run their own email server, or
bought some Free Software-based plug computing system that purports to be a
“home cloud” service with email. There’s virtually no chance
that such users would bother to figure all this out. They’d see their
email blocked, declare the “home cloud” solution useless, and
would just get a gmail.com, outlook.com, or some other third-party email
account. Thus, I predict that software freedom that we once had, for our
MTAs and MUAs, will eventually evaporate for everyone except those tiny few
who invest the time to understand these complexities and fight the
for-profit corporate power that curtails software freedom. Furthermore,
that struggle becomes Sisyphean as our numbers dwindle.

Email is the oldest software-centric communication system on the planet.
The global email system serves as a canary in the coalmine regarding
software freedom and network service freedom issues. Frighteningly,
software now controls most of the global communications systems. How long
will it be before mobile network providers refuse to terminate PSTN calls
or SMS’s sent from devices running modified Android firmwares like
Replicant? Perhaps those providers, like large email providers, will argue
that preventing robocalls (the telephone equivalent of SPAM) necessitates
such blocking. Such network effects place so many dystopias on
software freedom’s horizon.

I don’t deny that every day, there is more Free Software existing in the
world than has ever existed before — the P.T. Barnum’s of Open Source
have that part right. The part they leave out is that, each day, their
corporate backers make it a little more difficult to complete mundane tasks
using only Free Software. Open Source wins the battle while software
freedom loses the war.

0Yes, I’m intimately
aware that Elm’s license was non-free, and that the software
freedom of PINE’s license was in question. That’s slightly
relevant here but mostly orthogonal to this point, because Free
Software MUAs were still very common then, and there were
(ultimately successful) projects
to actively rewrite the ones whose software freedom was in
question

1For the last five
years, one of Conservancy’s Director Emeriti, Loïc Dachary,
has donated an extensive amount of personal time and
in-kind donations by providing Cloud server for Conservancy to
host its three key servers, including the email server. The
burden of maintaining this for us became too time consuming (very
reasonably), and Loïc’s asked us to find another provider. I
want, BTW, to thank Loïc his for years of volunteer work
maintaining infrastructure for us; he provided this service for
much longer than we could have hoped! Loïc also gave us
plenty of warning that we’d need to move. None of these problems
are his fault in the least!

2The
obvious supposition is that, because IPv4 numbers are so scarce,
this particular IP number was likely used previously by a spammer
who was shut down.

3I of
course didn’t count the time time on phone hold, as I was able to
do other work while waiting, but less efficiently because the hold
music was very distracting.

4If you want to
see if someone’s domain is a Microsoft customer, see if the MX
record for their domain (say, example.org) points to
example-org.mail.protection.outlook.com.

Debugging SMTP Conversations Part 1: How to Speak SMTP

Post Syndicated from Elton Pinto original http://sesblog.amazon.com/post/Tx1FLLVZQB8HI2Z/Debugging-SMTP-Conversations-Part-1-How-to-Speak-SMTP

Amazon SES strives to make your email sending as simple and quick as possible, which means that users of our HTTP API don’t even have to worry about what an SMTP conversation is or how to capture one. Even a lot of our SMTP interface users outsource the problem to software like Microsoft Outlook or PHP Mailer that takes care of these details for them. But if you’re experiencing an issue sending mail that can’t be explained by a recent code change or an error message from SES, understanding how an SMTP conversation works can be helpful. Or maybe you’re just curious as to what those bits flying around look like. In today’s blog post, the first in a series to help you debug these issues, we’ll go over the basics of an SMTP conversation.

Conversational SMTP

The Simple Mail Transfer Protocol (SMTP) was first officially put into writing in 1982 in RFC 821 as a way to “transfer mail reliably and efficiently”, but the protocol that the majority of ISPs use today is described in RFC 5321. The protocol includes a basic handshake, supported commands and responses at each step of the conversation, and finally transmission of message content. Here is a summary of the various steps of a typical conversation, without any extensions involved:

An SMTP client opens a connection with an SMTP server. Generally, this is on port 25 or 587.

The SMTP server responds with a 220 code and may follow that with a header that describes the server. It could also respond with a 554 status code to reject the connection, and then the client’s only option would be the QUIT command.

The SMTP client sends either an EHLO or HELO command to the server. Either command must be followed by a space and then the domain of the client. Contemporary clients and servers should support EHLO, so EHLO is what we’ll use in this example. 

The SMTP server should respond to the EHLO with the 250 status code, its domain name, and a server greeting, and one line for every SMTP extension it supports.

Now the SMTP client is in business and can start defining the mail to be sent, starting with what’s commonly referred to as the “envelope from” header. The client sends “MAIL FROM:” followed by a reverse-path address, which defines where bounce messages are sent if the message can’t be delivered after it’s accepted (receiving MTAs add this to incoming mail with the Return-Path header). If the mail being sent is a bounce message, this address should be empty (i.e., “<>”). The reverse-path address can optionally be followed by mail parameters defined by a supported SMTP extension (as advertised in the EHLO reply). The conversation cannot proceed until this MAIL FROM command is sent and accepted.

The SMTP server must accept the MAIL FROM with a “250 OK” reply if the format is good and the address is deemed acceptable. Otherwise, the server typically responds with a 550 or 553 error response to indicate whether the failure is temporary or permanent. Other acceptable error status codes are 552, 451, 452, 503, 455, and 555 (see RFC 5321 for their definitions).

The SMTP client can now define whom the email is for using the RCPT TO command. The syntax is very similar to MAIL FROM: it must be the literal “RCPT TO:” followed by the forward-path address surrounded by angle brackets. This can also optionally be followed by any parameters necessary to use an SMTP extension advertised in the EHLO reply. The RCPT TO command can only define a single recipient. If there are multiple recipients, the command can be issued multiple times, but the client needs to wait for a response from the server each time before supplying another destination.

The SMTP server usually validates that the address is deliverable and responds with “250 OK” if it is. Otherwise, it typically returns a 550 reply. Other acceptable error status codes are 551, 552, 553, 450, 451, 452, 503, 455, and 555 (see RFC 5321 for their definitions). Some servers will accept all mail and only validate the destination after the SMTP conversation has completed.   

Finally, the SMTP client can initiate sending the body of the email by issuing the DATA command with no other text after it.

The SMTP server responds with a 354 reply if it is ready to accept the message, or else a 503 or 554 if there was no valid MAIL FROM or RCPT TO command sent.

If the SMTP server responded with a 354 reply, the client submits the message text, followed by the end of mail data indicator, which is a line containing only a period. The message generally starts with headers (one per line, e.g., “Header-name: header-value”) and then is followed by the body of the message.

If the message is accepted, the SMTP server replies with a “250 OK” reply.

The client can now initiate a new conversation with the server or send the “QUIT” command to politely close out the connection.

If the SMTP server receives a QUIT, it is supposed to send a “221 OK” reply and then close the connection.

For deeper details of SMTP, please refer to RFC 5321. You can communicate with SES via SMTP over a number of clients including Microsoft Outlook – see the developer guide for more details. If you’d like to see the conversation yourself, you can also use telnet. There are a few additional things worth noting:

The server must not intentionally close the connection unless it sees a QUIT command except in the case of a timeout or if the server has to go down.

At any time during the conversation, the SMTP client can send the RSET command (just “RSET”, no additional parameters) to abort the current mail transaction so that the conversation can start fresh.

Other supported commands are VRFY to verify that a string represents a valid user or mailbox, EXPN to confirm that a string identifies a mailing list and returns membership of that list, NOOP to get a “250 OK” reply from the server, and HELP to get help information.

One notable extension that Amazon SES supports for secure communication on ports 25, 587, and 2587 is STARTTLS, as detailed in RFC 3207. After the EHLO, the client sends the command “STARTTLS”, the server replies with “220 Ready to start TLS” (or 501 or 454 error codes), and then TLS negotiation occurs to set up encryption keys. The conversation is then reset and must start with EHLO all over again with all transactions from here on out encrypted. Amazon SES also supports TLS wrapper mode on ports 465 and 2465.

Another notable extension that Amazon SES requires for authentication is AUTH PLAIN LOGIN, which is where you would enter your SMTP credentials. This is explained in some detail in the Developer’s Guide, but a recent blog post also goes into authentication in general.

Here is a sample SMTP conversation with SES in TLS wrapper mode with the conversation contents decrypted. The blue text comes from Amazon SES and the red text comes from a sample client:

PROXY TCP4 74.120.248.95 10.44.15.76 14659 465

220 email-smtp.amazonaws.com ESMTP SimpleEmailService-793939519 iqAfLvOj6BjiiCjSnD6S

EHLO email-smtp.us-east-1.amazonaws.com

250-email-smtp.amazonaws.com

250-8BITMIME

250-SIZE 10485760

250-AUTH PLAIN LOGIN

250 Ok

AUTH LOGIN

334 VXNlcm5hbWU6

bXlfZmFrZV91c2VybmFtZQ==

334 UGFzc3dvcmQ6

bXlfZmFrZV9wYXNzd29yZA==

235 Authentication successful.

MAIL FROM:<[email protected]>

250 Ok

RCPT TO:<[email protected]>

250 Ok

DATA

354 End data with <CR><LF>.<CR><LF>

MIME-Version: 1.0

Subject: Test message

From: Senior Tester <[email protected]>

Content-Type: text/html; charset="UTF-8"

Content-Transfer-Encoding: quoted-printable

To: [email protected]>

<b>Cool email body</b>

.

250 Ok 0000012345678e09-123a4cdc-b56c-78dd-b90e-d123be456789-000000

QUIT

221 Bye

We hope that you feel better informed now on how email works at a high level! In the next post of this series we’ll go over how you can easily capture a live SMTP conversation. Thanks for being a customer of Amazon SES!

Debugging SMTP Conversations Part 1: How to Speak SMTP

Post Syndicated from Elton Pinto original http://sesblog.amazon.com/post/Tx1FLLVZQB8HI2Z/Debugging-SMTP-Conversations-Part-1-How-to-Speak-SMTP

Amazon SES strives to make your email sending as simple and quick as possible, which means that users of our HTTP API don’t even have to worry about what an SMTP conversation is or how to capture one. Even a lot of our SMTP interface users outsource the problem to software like Microsoft Outlook or PHP Mailer that takes care of these details for them. But if you’re experiencing an issue sending mail that can’t be explained by a recent code change or an error message from SES, understanding how an SMTP conversation works can be helpful. Or maybe you’re just curious as to what those bits flying around look like. In today’s blog post, the first in a series to help you debug these issues, we’ll go over the basics of an SMTP conversation.

Conversational SMTP

The Simple Mail Transfer Protocol (SMTP) was first officially put into writing in 1982 in RFC 821 as a way to “transfer mail reliably and efficiently”, but the protocol that the majority of ISPs use today is described in RFC 5321. The protocol includes a basic handshake, supported commands and responses at each step of the conversation, and finally transmission of message content. Here is a summary of the various steps of a typical conversation, without any extensions involved:

An SMTP client opens a connection with an SMTP server. Generally, this is on port 25 or 587.

The SMTP server responds with a 220 code and may follow that with a header that describes the server. It could also respond with a 554 status code to reject the connection, and then the client’s only option would be the QUIT command.

The SMTP client sends either an EHLO or HELO command to the server. Either command must be followed by a space and then the domain of the client. Contemporary clients and servers should support EHLO, so EHLO is what we’ll use in this example. 

The SMTP server should respond to the EHLO with the 250 status code, its domain name, and a server greeting, and one line for every SMTP extension it supports.

Now the SMTP client is in business and can start defining the mail to be sent, starting with what’s commonly referred to as the “envelope from” header. The client sends “MAIL FROM:” followed by a reverse-path address, which defines where bounce messages are sent if the message can’t be delivered after it’s accepted (receiving MTAs add this to incoming mail with the Return-Path header). If the mail being sent is a bounce message, this address should be empty (i.e., “<>”). The reverse-path address can optionally be followed by mail parameters defined by a supported SMTP extension (as advertised in the EHLO reply). The conversation cannot proceed until this MAIL FROM command is sent and accepted.

The SMTP server must accept the MAIL FROM with a “250 OK” reply if the format is good and the address is deemed acceptable. Otherwise, the server typically responds with a 550 or 553 error response to indicate whether the failure is temporary or permanent. Other acceptable error status codes are 552, 451, 452, 503, 455, and 555 (see RFC 5321 for their definitions).

The SMTP client can now define whom the email is for using the RCPT TO command. The syntax is very similar to MAIL FROM: it must be the literal “RCPT TO:” followed by the forward-path address surrounded by angle brackets. This can also optionally be followed by any parameters necessary to use an SMTP extension advertised in the EHLO reply. The RCPT TO command can only define a single recipient. If there are multiple recipients, the command can be issued multiple times, but the client needs to wait for a response from the server each time before supplying another destination.

The SMTP server usually validates that the address is deliverable and responds with “250 OK” if it is. Otherwise, it typically returns a 550 reply. Other acceptable error status codes are 551, 552, 553, 450, 451, 452, 503, 455, and 555 (see RFC 5321 for their definitions). Some servers will accept all mail and only validate the destination after the SMTP conversation has completed.   

Finally, the SMTP client can initiate sending the body of the email by issuing the DATA command with no other text after it.

The SMTP server responds with a 354 reply if it is ready to accept the message, or else a 503 or 554 if there was no valid MAIL FROM or RCPT TO command sent.

If the SMTP server responded with a 354 reply, the client submits the message text, followed by the end of mail data indicator, which is a line containing only a period. The message generally starts with headers (one per line, e.g., “Header-name: header-value”) and then is followed by the body of the message.

If the message is accepted, the SMTP server replies with a “250 OK” reply.

The client can now initiate a new conversation with the server or send the “QUIT” command to politely close out the connection.

If the SMTP server receives a QUIT, it is supposed to send a “221 OK” reply and then close the connection.

For deeper details of SMTP, please refer to RFC 5321. You can communicate with SES via SMTP over a number of clients including Microsoft Outlook – see the developer guide for more details. If you’d like to see the conversation yourself, you can also use telnet. There are a few additional things worth noting:

The server must not intentionally close the connection unless it sees a QUIT command except in the case of a timeout or if the server has to go down.

At any time during the conversation, the SMTP client can send the RSET command (just “RSET”, no additional parameters) to abort the current mail transaction so that the conversation can start fresh.

Other supported commands are VRFY to verify that a string represents a valid user or mailbox, EXPN to confirm that a string identifies a mailing list and returns membership of that list, NOOP to get a “250 OK” reply from the server, and HELP to get help information.

One notable extension that Amazon SES supports for secure communication on ports 25, 587, and 2587 is STARTTLS, as detailed in RFC 3207. After the EHLO, the client sends the command “STARTTLS”, the server replies with “220 Ready to start TLS” (or 501 or 454 error codes), and then TLS negotiation occurs to set up encryption keys. The conversation is then reset and must start with EHLO all over again with all transactions from here on out encrypted. Amazon SES also supports TLS wrapper mode on ports 465 and 2465.

Another notable extension that Amazon SES requires for authentication is AUTH PLAIN LOGIN, which is where you would enter your SMTP credentials. This is explained in some detail in the Developer’s Guide, but a recent blog post also goes into authentication in general.

Here is a sample SMTP conversation with SES in TLS wrapper mode with the conversation contents decrypted. The blue text comes from Amazon SES and the red text comes from a sample client:

PROXY TCP4 74.120.248.95 10.44.15.76 14659 465

220 email-smtp.amazonaws.com ESMTP SimpleEmailService-793939519 iqAfLvOj6BjiiCjSnD6S

EHLO email-smtp.us-east-1.amazonaws.com

250-email-smtp.amazonaws.com

250-8BITMIME

250-SIZE 10485760

250-AUTH PLAIN LOGIN

250 Ok

AUTH LOGIN

334 VXNlcm5hbWU6

bXlfZmFrZV91c2VybmFtZQ==

334 UGFzc3dvcmQ6

bXlfZmFrZV9wYXNzd29yZA==

235 Authentication successful.

MAIL FROM:<[email protected]>

250 Ok

RCPT TO:<[email protected]>

250 Ok

DATA

354 End data with <CR><LF>.<CR><LF>

MIME-Version: 1.0

Subject: Test message

From: Senior Tester <[email protected]>

Content-Type: text/html; charset="UTF-8"

Content-Transfer-Encoding: quoted-printable

To: [email protected]>

<b>Cool email body</b>

.

250 Ok 0000012345678e09-123a4cdc-b56c-78dd-b90e-d123be456789-000000

QUIT

221 Bye

We hope that you feel better informed now on how email works at a high level! In the next post of this series we’ll go over how you can easily capture a live SMTP conversation. Thanks for being a customer of Amazon SES!

What Happens When You Reach Your Sending Limits?

Post Syndicated from Wendy Giberson original http://sesblog.amazon.com/post/Tx8YGT0YZ9SQLD/What-Happens-When-You-Reach-Your-Sending-Limits

As you probably know, Amazon SES has a set of sending limits to control how many emails you can send per 24 hours (your daily sending quota) and how many emails you can send per second (your maximum send rate). Although these limits might seem, well, limiting, we have them in place to protect you. Many ISPs consider sudden spikes in email rate or volume from a particular sender or IP address to be indicative of someone trying to send spam. If you ramp up your email sending in a controlled manner, your emails are less likely to be flagged as spam and more likely to end up in your recipients’ inboxes.
You can increase your sending limits by sending high-quality emails at or near your current sending limits so that Amazon SES ramps you up gradually, or you can file an Extended Access Request if you need to increase your sending limits right away. Both methods are explained in the Amazon SES Developer Guide and the recent blog post on Managing Your Amazon SES Quota. However, today’s blog post is about what happens when you reach your limits, whatever those may be.
Ultimately, when you call Amazon SES to send an email after you’ve reached one of your sending limits, the call fails with a throttling error and the email is dropped. Amazon SES does not queue the emails and send them later. How your application receives the throttling error depends on whether it accesses Amazon SES through the API or the SMTP interface, as described below.
Amazon SES API
If you try to exceed your sending limits when you are accessing Amazon SES through the API using a programming language that uses exceptions, then your application will encounter a ThrottlingException:

ThrottlingException – Daily message quota exceeded
ThrottlingException – Maximum sending rate exceeded

If you are accessing the Amazon SES API through the Amazon SES HTTP interface directly, you will receive an HTTP status code of 400 with an error of type Throttling. (For other raw HTTP errors, see Common Errors.)
SMTP Interface
If you are accessing Amazon SES through the SMTP interface, your SMTP client will receive one of these errors:

454 Throttling failure: Daily message quota exceeded
454 Throttling failure: Maximum sending rate exceeded

However, the way you experience these errors depends on the SMTP client you are using. Different SMTP clients notify you in different ways, so we can’t tell you exactly what you will see. For example, Microsoft Outlook reports a “Send/Receive” error in the status bar at the bottom of the Outlook window, and if you read the fine print it mentions the 454 throttling failure. Other SMTP clients may not be so descriptive or report the error at all.
Sending To Multiple Recipients
What happens when you reach your sending limits when you send an email to multiple recipients in one call to Amazon SES? Before I get into it, I first want to emphasize that we do not recommend that you send an email to multiple recipients in one call to SendEmail at all. Really – it’s best not to do this. For example, if one of those addresses is on the blacklist, the entire email will be rejected and none of the recipients will get the intended email. Also, a message with multiple recipients may be indicative to ISPs of spam because the email can’t be personalized for each recipient. It’s much better to call SendEmail once for every recipient.
Anyway, regarding what happens when you hit your limits during a call to send to multiple recipients – first remember that normally, sending limits are based on recipients rather than on messages. For example, an email to five recipients counts as five against your daily sending quota. When you send to multiple recipients, though, if you have any emails remaining in your daily sending quota, then your API call (as long as other factors are ok, like none of the addresses are on the blacklist) will go through. Keep in mind however that the amount you have left in your daily sending quota is being continuously calculated by Amazon SES, so it’s not good to be hovering too close to this limit. If you find yourself frequently cutting it this close, submit an Extended Access Request.
It’s a similar story with your send rate quota – if, at the rate you are sending, you have any emails left in your send rate quota, you can send to multiple recipients. However, you will not be able to send further emails until you have built up enough quota again. For example, if your send rate quota is one message per second, and you send a message to five recipients at once, Amazon SES lets you do that. For the next five seconds, though, Amazon will return errors for all send attempts. Once five seconds have passed, you’ll have available quota and you will be able to send again. This way, emails with many recipients can get through, and they’ll get through at the overall rate allowed by the quota.
However, you probably don’t need to worry about the multiple-recipient case at all, because you are sending to one recipient at a time as we recommend, right? Amazon SES is designed to work seamlessly with your email application when you do so.
And Remember…
Plan ahead! Don’t wait until you hit your sending limits to think about extending them. Stay on top of where you are with respect to your quota by using the Amazon SES console or by calling the GetSendQuota API, and see the Amazon SES Developer Guide and Managing Your Amazon SES Quota for information about how to increase your limits.
Thank you for using Amazon SES! 

What Happens When You Reach Your Sending Limits?

Post Syndicated from Wendy Giberson original http://sesblog.amazon.com/post/Tx8YGT0YZ9SQLD/What-Happens-When-You-Reach-Your-Sending-Limits

As you probably know, Amazon SES has a set of sending limits to control how many emails you can send per 24 hours (your daily sending quota) and how many emails you can send per second (your maximum send rate). Although these limits might seem, well, limiting, we have them in place to protect you. Many ISPs consider sudden spikes in email rate or volume from a particular sender or IP address to be indicative of someone trying to send spam. If you ramp up your email sending in a controlled manner, your emails are less likely to be flagged as spam and more likely to end up in your recipients’ inboxes.
You can increase your sending limits by sending high-quality emails at or near your current sending limits so that Amazon SES ramps you up gradually, or you can file an Extended Access Request if you need to increase your sending limits right away. Both methods are explained in the Amazon SES Developer Guide and the recent blog post on Managing Your Amazon SES Quota. However, today’s blog post is about what happens when you reach your limits, whatever those may be.
Ultimately, when you call Amazon SES to send an email after you’ve reached one of your sending limits, the call fails with a throttling error and the email is dropped. Amazon SES does not queue the emails and send them later. How your application receives the throttling error depends on whether it accesses Amazon SES through the API or the SMTP interface, as described below.
Amazon SES API
If you try to exceed your sending limits when you are accessing Amazon SES through the API using a programming language that uses exceptions, then your application will encounter a ThrottlingException:

ThrottlingException – Daily message quota exceeded
ThrottlingException – Maximum sending rate exceeded

If you are accessing the Amazon SES API through the Amazon SES HTTP interface directly, you will receive an HTTP status code of 400 with an error of type Throttling. (For other raw HTTP errors, see Common Errors.)
SMTP Interface
If you are accessing Amazon SES through the SMTP interface, your SMTP client will receive one of these errors:

454 Throttling failure: Daily message quota exceeded
454 Throttling failure: Maximum sending rate exceeded

However, the way you experience these errors depends on the SMTP client you are using. Different SMTP clients notify you in different ways, so we can’t tell you exactly what you will see. For example, Microsoft Outlook reports a “Send/Receive” error in the status bar at the bottom of the Outlook window, and if you read the fine print it mentions the 454 throttling failure. Other SMTP clients may not be so descriptive or report the error at all.
Sending To Multiple Recipients
What happens when you reach your sending limits when you send an email to multiple recipients in one call to Amazon SES? Before I get into it, I first want to emphasize that we do not recommend that you send an email to multiple recipients in one call to SendEmail at all. Really – it’s best not to do this. For example, if one of those addresses is on the blacklist, the entire email will be rejected and none of the recipients will get the intended email. Also, a message with multiple recipients may be indicative to ISPs of spam because the email can’t be personalized for each recipient. It’s much better to call SendEmail once for every recipient.
Anyway, regarding what happens when you hit your limits during a call to send to multiple recipients – first remember that normally, sending limits are based on recipients rather than on messages. For example, an email to five recipients counts as five against your daily sending quota. When you send to multiple recipients, though, if you have any emails remaining in your daily sending quota, then your API call (as long as other factors are ok, like none of the addresses are on the blacklist) will go through. Keep in mind however that the amount you have left in your daily sending quota is being continuously calculated by Amazon SES, so it’s not good to be hovering too close to this limit. If you find yourself frequently cutting it this close, submit an Extended Access Request.
It’s a similar story with your send rate quota – if, at the rate you are sending, you have any emails left in your send rate quota, you can send to multiple recipients. However, you will not be able to send further emails until you have built up enough quota again. For example, if your send rate quota is one message per second, and you send a message to five recipients at once, Amazon SES lets you do that. For the next five seconds, though, Amazon will return errors for all send attempts. Once five seconds have passed, you’ll have available quota and you will be able to send again. This way, emails with many recipients can get through, and they’ll get through at the overall rate allowed by the quota.
However, you probably don’t need to worry about the multiple-recipient case at all, because you are sending to one recipient at a time as we recommend, right? Amazon SES is designed to work seamlessly with your email application when you do so.
And Remember…
Plan ahead! Don’t wait until you hit your sending limits to think about extending them. Stay on top of where you are with respect to your quota by using the Amazon SES console or by calling the GetSendQuota API, and see the Amazon SES Developer Guide and Managing Your Amazon SES Quota for information about how to increase your limits.
Thank you for using Amazon SES!