Business Source (A software license with some Open Source aspects)

Post Syndicated from Monty original http://monty-says.blogspot.com/2013/06/business-source-software-license-with.html

A couple of weeks ago I was interviewed on ZDNET about how to create successful software company in todays world. I assume that because the original article also mentioned my other project, MariaDB, some people jumped to the wrong conclusion about my intentions or what I was trying to achieve. For those that want to know more about Business Source, there is now an academic article in TIM (Technology Innovation Management Review) that one can read. The article is written by Linus Nyman and me. To clarify some misunderstandings, here is a short list of what the Business Source license is all about: Business Source is not an Open Source license. It’s a commercial software license that offers the users many of the benefits of an Open Source license. Business Source means that all source code is available from day one and that most (but not all) users can use it any way for free. After a time delay the software becomes Open Source. Business Source was never intended for the MariaDB server. MariaDB is GPL and will always be that. I could not change the license for the MariaDB server even if I wanted to (and I never wanted to make MySQL or MariaDB closed source or Open core). I truly belive that Open Source is a better way to develop software. However as an entrepreneur I recognize that it’s very hard to create a software development company around Open Source. Dual licenses works for some cases (especially for infrastructure and embeddable software like MySQL), but doesn’t work for a lot of software. It’s also very hard to fund development with services (support, development, consulting…) as the profit from these (typically 30%) are not enough to maintain a development organization in many cases. For a software company that wants to do development and compete with closed source companies on similar economic terms, Business Source offers a viable alternative to closed source or open core. For a user of the software, Business Source is always better than Open Core as Open Core doesn’t offer for it’s user ANY of the advantages of Open Source. While searching for companies that my investment company, Open Ocean Capital, can invest into, I have been talking with a lot of entrepreneurs about how to make money on their software. In some cases where the entrepreneurs would like to release their software as Open Source but don’t know how to make enough money to support development, I have told them to take a look at Business Source. As an Open Source/Free Software advocate it feels a bit bad to have to turn away some companies from Open Source, but I think that in the long run it’s better that the companies succeed and produces good software that is accessible to anyone under reasonable terms. Compared to other license models, at least with Business Source the software will eventually become Open Source. The article should hopefully explain any other questions you have about Business Source. If not, feel free to comment on this blog and I will do my best to clarify things. By the way, I am not totally happy with the term “Business Source” as there is already a company that uses this name. Business Source (or Source for Business) is however the best term I have come up with for this license so far. If you have a better suggestion for the name, please write me a comment!

Amazon SES Console Redesign

Post Syndicated from Wendy Giberson original http://sesblog.amazon.com/post/Tx12G92H0LGA7EP/Amazon-SES-Console-Redesign

AWS has been gradually rolling out an improved user interface for the AWS Management Console of different services, and today is SES’s turn! The goal of the console redesign is to enable you to access the same underlying SES functionality more easily, especially on tablet devices. Whether you access the SES console using a desktop computer or a tablet, you will find the redesigned console to be easier to read and easier to use.
Easier to read
   •  Larger, easier-to-read text and improved spacing within tables.
   •  Optimal use of screen space so you can see more information at one time.
   •  The Navigation pane is collapsible to allow more room for information within the main window.
Easier to use
   •  All details of a verified sender are shown together. You no longer need to click on tabs to switch between verification status, feedback forwarding, and DKIM settings.
   •  You can view the details of multiple verified senders at once by individually expanding the information for different verified senders in the list. 
   •  Your sending limits and sending metrics are now highly visible at the top of the Dashboard.
   •  Buttons are larger and more prominent, which will help tablet users.
Thoughts on the console redesign? We’d love to hear from you in the forum
Thanks for using SES!

Amazon SES Console Redesign

Post Syndicated from Wendy Giberson original http://sesblog.amazon.com/post/Tx12G92H0LGA7EP/Amazon-SES-Console-Redesign

AWS has been gradually rolling out an improved user interface for the AWS Management Console of different services, and today is SES’s turn! The goal of the console redesign is to enable you to access the same underlying SES functionality more easily, especially on tablet devices. Whether you access the SES console using a desktop computer or a tablet, you will find the redesigned console to be easier to read and easier to use.
Easier to read
   •  Larger, easier-to-read text and improved spacing within tables.
   •  Optimal use of screen space so you can see more information at one time.
   •  The Navigation pane is collapsible to allow more room for information within the main window.
Easier to use
   •  All details of a verified sender are shown together. You no longer need to click on tabs to switch between verification status, feedback forwarding, and DKIM settings.
   •  You can view the details of multiple verified senders at once by individually expanding the information for different verified senders in the list. 
   •  Your sending limits and sending metrics are now highly visible at the top of the Dashboard.
   •  Buttons are larger and more prominent, which will help tablet users.
Thoughts on the console redesign? We’d love to hear from you in the forum
Thanks for using SES!

Вторник, 18 Юни 2013

Post Syndicated from georgi original http://georgi.unixsol.org/diary/archive.php/2013-06-18

Докато хората протестират на площадите, бизнеса тихомълком смазва правилните
места, за да върви всичко по мед и масло.
Резултатът е следното разпореждане (razporezhdane_za_spirane.pdf (788K)),
което задължава интернет доставчиците да започнат да филтрират достъпа до следния
списък от домейни (spisak_stranici.pdf (68K)).
Днес хазарта, утре и други неща. На печелившите честито.

GNOME.Asia and LinuxCon Japan

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/asia-2013.html

Two weeks ago I attended GNOME.Asia/Seoul and LinuxCon Japan/Tokyo, thanks
to sponsoring by the GNOME Foundation and the Linux Foundation. At GNOME.Asia I
spoke about Sandboxed
Applications for GNOME
, and at LinuxCon Japan about the first
three years of systemd
. (I think at least the latter one was videotaped,
and recordings might show up on the net eventually). I like to believe both
talks went pretty well, and helped getting the message across to community what
we are working on and what the roadmap for us is, and what we expect from the
various projects, and especially GNOME. However, for me personally the
hallway track was the most interesting part. The personal Q&A regarding
our work on kdbus, cgroups, systemd and related projects where highly
interesting. In fact, at both conferences we had something like impromptu
hackfests on the topics of kdbus and cgroups, with some conferences attendees.
I also enjoyed the opportunity to be on Karen’s upcoming GNOME podcast,
recorded in a session at Gyeongbokgung Palace in Seoul (what better place could
there be for a podcast recording?).

I’d like to thank the GNOME and Linux foundations for sponsoring my attendance to these conferences. I’d especially like to thank the organizers of GNOME.Asia for their perfectly organized conference!

GNOME.Asia and LinuxCon Japan

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/asia-2013.html

Two weeks ago I attended GNOME.Asia/Seoul and LinuxCon Japan/Tokyo, thanks
to sponsoring by the GNOME Foundation and the Linux Foundation. At GNOME.Asia I
spoke about Sandboxed
Applications for GNOME
, and at LinuxCon Japan about the first
three years of systemd
. (I think at least the latter one was videotaped,
and recordings might show up on the net eventually). I like to believe both
talks went pretty well, and helped getting the message across to community what
we are working on and what the roadmap for us is, and what we expect from the
various projects, and especially GNOME. However, for me personally the
hallway track was the most interesting part. The personal Q&A regarding
our work on kdbus, cgroups, systemd and related projects where highly
interesting. In fact, at both conferences we had something like impromptu
hackfests on the topics of kdbus and cgroups, with some conferences attendees.
I also enjoyed the opportunity to be on Karen’s upcoming GNOME podcast,
recorded in a session at Gyeongbokgung Palace in Seoul (what better place could
there be for a podcast recording?).

I’d like to thank the GNOME and Linux foundations for sponsoring my attendance to these conferences. I’d especially like to thank the organizers of GNOME.Asia for their perfectly organized conference!

GNOME.Asia and LinuxCon Japan

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/asia-2013.html

Two weeks ago I attended GNOME.Asia/Seoul and LinuxCon Japan/Tokyo, thanks
to sponsoring by the GNOME Foundation and the Linux Foundation. At GNOME.Asia I
spoke about Sandboxed
Applications for GNOME
, and at LinuxCon Japan about the first
three years of systemd
. (I think at least the latter one was videotaped,
and recordings might show up on the net eventually). I like to believe both
talks went pretty well, and helped getting the message across to community what
we are working on and what the roadmap for us is, and what we expect from the
various projects, and especially GNOME. However, for me personally the
hallway track was the most interesting part. The personal Q&A regarding
our work on kdbus, cgroups, systemd and related projects where highly
interesting. In fact, at both conferences we had something like impromptu
hackfests on the topics of kdbus and cgroups, with some conferences attendees.
I also enjoyed the opportunity to be on Karen’s upcoming GNOME podcast,
recorded in a session at Gyeongbokgung Palace in Seoul (what better place could
there be for a podcast recording?).

I’d like to thank the GNOME and Linux foundations for sponsoring my attendance to these conferences. I’d especially like to thank the organizers of GNOME.Asia for their perfectly organized conference!

Three places where your email could get delayed when sending through SES

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/Tx1S0ND7F4PCCGN/Three-places-where-your-email-could-get-delayed-when-sending-through-SES

Email sending is one of those activities you may not pay much attention to when all goes well, but you really notice when it’s not working. In today’s fast moving world, the speed of information transfer is critical, so slow email delivery is a particularly painful problem. In this blog post, we will explore three places where your emails could be delayed before your recipients get a chance to read them.
The typical path of an email message delivered via Amazon SES is pretty simple: your application generates the email and then passes it to SES in one way or another. After a brief period spent inside the SES pipeline, SES attempts to contact the receiving ISP and deliver the message. The ISP, after successfully enqueuing the message, displays it to the intended recipient. Let’s see now what could go wrong at each of these steps, and how we can identify the source of the problem.
Scenario 1: Emails are delayed before arriving at SES
The first step in the process is for your application to contact SES to pass it the message. This is one place where problems could occur.
Remember that for each message it successfully enqueues, SES returns a message ID that you can log on your side. To verify that your calls are actually successful, you can track these message IDs. If SES never accepted your message, you can be sure it won’t be delivered! If you are able to log a message ID, it means that your email safely arrived in SES. You can then match the timestamp of when the message ID was logged with the timestamp of when the call was made inside your application. If the difference is too big, it means something happened between the moment your application wanted to send the email and until SES acknowledged its receipt.
Typical problems we’ve seen include custom software (such as Postfix) sitting between the customer’s application and SES, which were buffering or otherwise delaying messages. If you have such a setup, make sure you examine the logs of the software you’re using for evidence of any delays there.  
In order to test that the problem lies between your application and SES, and not inside SES or between SES and the ISP, you can try to send a test email from the Amazon SES console to that specific ISP. If that test email arrives on time, it’s a pretty good indicator that the delay is occurring before your email even reaches SES.
Scenario 2: Emails are delayed inside SES
Once SES accepts the message, it will process it as quickly as possible, before handing it over to the ISP. We take latency very seriously, and, in the event of significant service delays, we will update the public status dashboard.
Soft bounces and Amazon SES
SES service delays are, however, not the only reason why emails might not be delivered to the receiving end. For various reasons, the ISP might be temporarily refusing your email. This is referred to as a soft bounce. Typical reasons why ISPs might soft bounce your email are if the destination address has a full inbox, the email is of a larger size than they support, or they have a service issue and cannot accept email. ISPs can also soft bounce emails as a form of throttling – if they see too many emails delivered too quickly they sometimes interpret that as a spammer trying to attack their customers.
When a soft bounce event happens, SES continuously retries to deliver your email for 12 hours before giving up. There is no limit of retries during this 12-hour interval, and, as long as the ISP recovers, your email will be delivered.
To verify whether soft bouncing is the issue, you can try sending to different ISPs. If you only see delays with one of them, that’s a pretty good indicator that that particular ISP has a problem receiving your email.
Scenario 3: Emails are delayed after leaving SES
One particularly thorny problem we sometimes encounter is when we successfully deliver the email to an ISP quickly and in the first attempt, only to have it take a very long time to appear in the recipient’s inbox. This can happen for a variety of reasons, for example the ISP is encountering a technical problem, or it is delaying making the email available to its users because it does not yet trust it.
To narrow down the problem, try sending to a different ISP (or to a different address in the same ISP), using an email with different content, different (or lack of) attachments, different “From” address, etc. and see if that makes a difference. Remember that as long as you haven’t received a bounce notification from Amazon SES, it means your message is either somewhere in the SES pipeline, with its delivery being continuously retried, or it has already been enqueued by the ISP, and it being processed on their end.
We hope this entry sheds a bit more light over email latencies and SES and will help you identify the source of the problem. Feel free to post any comments or questions for us in the AWS Forum.

Three places where your email could get delayed when sending through SES

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/Tx1S0ND7F4PCCGN/Three-places-where-your-email-could-get-delayed-when-sending-through-SES

Email sending is one of those activities you may not pay much attention to when all goes well, but you really notice when it’s not working. In today’s fast moving world, the speed of information transfer is critical, so slow email delivery is a particularly painful problem. In this blog post, we will explore three places where your emails could be delayed before your recipients get a chance to read them.
The typical path of an email message delivered via Amazon SES is pretty simple: your application generates the email and then passes it to SES in one way or another. After a brief period spent inside the SES pipeline, SES attempts to contact the receiving ISP and deliver the message. The ISP, after successfully enqueuing the message, displays it to the intended recipient. Let’s see now what could go wrong at each of these steps, and how we can identify the source of the problem.
Scenario 1: Emails are delayed before arriving at SES
The first step in the process is for your application to contact SES to pass it the message. This is one place where problems could occur.
Remember that for each message it successfully enqueues, SES returns a message ID that you can log on your side. To verify that your calls are actually successful, you can track these message IDs. If SES never accepted your message, you can be sure it won’t be delivered! If you are able to log a message ID, it means that your email safely arrived in SES. You can then match the timestamp of when the message ID was logged with the timestamp of when the call was made inside your application. If the difference is too big, it means something happened between the moment your application wanted to send the email and until SES acknowledged its receipt.
Typical problems we’ve seen include custom software (such as Postfix) sitting between the customer’s application and SES, which were buffering or otherwise delaying messages. If you have such a setup, make sure you examine the logs of the software you’re using for evidence of any delays there.  
In order to test that the problem lies between your application and SES, and not inside SES or between SES and the ISP, you can try to send a test email from the Amazon SES console to that specific ISP. If that test email arrives on time, it’s a pretty good indicator that the delay is occurring before your email even reaches SES.
Scenario 2: Emails are delayed inside SES
Once SES accepts the message, it will process it as quickly as possible, before handing it over to the ISP. We take latency very seriously, and, in the event of significant service delays, we will update the public status dashboard.
Soft bounces and Amazon SES
SES service delays are, however, not the only reason why emails might not be delivered to the receiving end. For various reasons, the ISP might be temporarily refusing your email. This is referred to as a soft bounce. Typical reasons why ISPs might soft bounce your email are if the destination address has a full inbox, the email is of a larger size than they support, or they have a service issue and cannot accept email. ISPs can also soft bounce emails as a form of throttling – if they see too many emails delivered too quickly they sometimes interpret that as a spammer trying to attack their customers.
When a soft bounce event happens, SES continuously retries to deliver your email for 12 hours before giving up. There is no limit of retries during this 12-hour interval, and, as long as the ISP recovers, your email will be delivered.
To verify whether soft bouncing is the issue, you can try sending to different ISPs. If you only see delays with one of them, that’s a pretty good indicator that that particular ISP has a problem receiving your email.
Scenario 3: Emails are delayed after leaving SES
One particularly thorny problem we sometimes encounter is when we successfully deliver the email to an ISP quickly and in the first attempt, only to have it take a very long time to appear in the recipient’s inbox. This can happen for a variety of reasons, for example the ISP is encountering a technical problem, or it is delaying making the email available to its users because it does not yet trust it.
To narrow down the problem, try sending to a different ISP (or to a different address in the same ISP), using an email with different content, different (or lack of) attachments, different “From” address, etc. and see if that makes a difference. Remember that as long as you haven’t received a bounce notification from Amazon SES, it means your message is either somewhere in the SES pipeline, with its delivery being continuously retried, or it has already been enqueued by the ISP, and it being processed on their end.
We hope this entry sheds a bit more light over email latencies and SES and will help you identify the source of the problem. Feel free to post any comments or questions for us in the AWS Forum.

DKIM Troubleshooting Series: Deliverability Considerations

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/Tx1AP19A27TEJNT/DKIM-Troubleshooting-Series-Deliverability-Considerations

Hello and welcome to the last entry in the Amazon SES DKIM troubleshooting blog series. So far, we have seen various technical problems that appeared between us and properly signed emails, and we also saw how DKIM helps protect our domain from various impersonators. We will now see whether DKIM can also improve our deliverability (the likelihood that our emails will arrive in our recipients’ Inboxes as opposed to their Spam or Junk folders).
Why are my emails still getting to the spam folder, even if I am properly using DKIM?
Ok, we have set up proper authentication, but now we need to focus on a new problem. Our emails are still arriving in the Spam folders of our customers for a major ISP. We cannot understand what’s wrong. Wasn’t DKIM supposed to prevent that?
DKIM is a great way to show ISPs that the emails we send actually belong to us. It also helps ISPs differentiate our traffic from other emails originating from the same IP address, by associating our email with our domain reputation. This way, we’re giving ISPs the opportunity to decide whether to place our emails in the Spam or Inbox based on our domain reputation regardless of the actual originating IP address.
What DKIM doesn’t do, however, is influence our domain’s actual standing with ISPs. By signing the email, our domain took responsibility for its content. If that content is unsolicited, for example, and the recipient clicks the "Report Spam" button, then we will be in trouble, and so will emails originating from our domain. Alternatively, if we are sending a high-quality email which is gladly accepted by our recipients, our good (domain) reputation will follow across outgoing IP addresses.
We start reading the Amazon SES Email Sending Best Practices whitepaper and discover the different building blocks of developing a rock-solid sending reputation. For example, we can start by analyzing our high complaint rate and investigating what we can do to reduce it. This is no longer a matter for this blog post though…
This seven part blog post series covered the most common issues we notice our customers having when they set up EasyDKIM with SES. We hope to have shed some light on details of this process that are more obscure on first sight. If you haven’t found the answer to your problem here, if the suggestions in these posts don’t work for you or if you just want to say hi, we invite you to post on the Amazon SES Forum and ask any questions you may have.
Happy sending and thank you for using SES!

DKIM Troubleshooting Series: Deliverability Considerations

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/Tx1AP19A27TEJNT/DKIM-Troubleshooting-Series-Deliverability-Considerations

Hello and welcome to the last entry in the Amazon SES DKIM troubleshooting blog series. So far, we have seen various technical problems that appeared between us and properly signed emails, and we also saw how DKIM helps protect our domain from various impersonators. We will now see whether DKIM can also improve our deliverability (the likelihood that our emails will arrive in our recipients’ Inboxes as opposed to their Spam or Junk folders).
Why are my emails still getting to the spam folder, even if I am properly using DKIM?
Ok, we have set up proper authentication, but now we need to focus on a new problem. Our emails are still arriving in the Spam folders of our customers for a major ISP. We cannot understand what’s wrong. Wasn’t DKIM supposed to prevent that?
DKIM is a great way to show ISPs that the emails we send actually belong to us. It also helps ISPs differentiate our traffic from other emails originating from the same IP address, by associating our email with our domain reputation. This way, we’re giving ISPs the opportunity to decide whether to place our emails in the Spam or Inbox based on our domain reputation regardless of the actual originating IP address.
What DKIM doesn’t do, however, is influence our domain’s actual standing with ISPs. By signing the email, our domain took responsibility for its content. If that content is unsolicited, for example, and the recipient clicks the "Report Spam" button, then we will be in trouble, and so will emails originating from our domain. Alternatively, if we are sending a high-quality email which is gladly accepted by our recipients, our good (domain) reputation will follow across outgoing IP addresses.
We start reading the Amazon SES Email Sending Best Practices whitepaper and discover the different building blocks of developing a rock-solid sending reputation. For example, we can start by analyzing our high complaint rate and investigating what we can do to reduce it. This is no longer a matter for this blog post though…
This seven part blog post series covered the most common issues we notice our customers having when they set up EasyDKIM with SES. We hope to have shed some light on details of this process that are more obscure on first sight. If you haven’t found the answer to your problem here, if the suggestions in these posts don’t work for you or if you just want to say hi, we invite you to post on the Amazon SES Forum and ask any questions you may have.
Happy sending and thank you for using SES!

DKIM Troubleshooting Series: Authentication Considerations

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/Tx2NCXUV8X3Z0WS/DKIM-Troubleshooting-Series-Authentication-Considerations

Hi, and welcome to another entry in the Amazon SES DKIM troubleshooting series. So far we have focused on technical issues, but now it’s time to take a step back and look at the bigger picture. Exactly why did we go to all this trouble in setting up DKIM for our domain?
My emails are signed and the signature validates. Does this mean I’m safe from spoofing attacks?
Even if all our email is DKIM signed and validated by all ISPs, this is no time to rest. The world is full of ethically dubious people who want to impersonate us and steal our customers, and DKIM is only step one in protecting ourselves.
So what exactly is DKIM doing to help us with this? The way this standard ensures the integrity of our emails is to calculate a hash of the message’s body and some of its headers, and then to digitally sign the hash. As long as the private key is kept secure, and the public key is accessible through DNS, the DKIM signature gives ISPs confidence that the domain that signs the message acknowledges its content through the signature. Let’s have another look at the DKIM signature to see exactly what we’re talking about:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=xtk53kxcy4p3t6ztbrffs6d54rsrrhh6; d=ses-example.com;
t=1366720445;
h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Date:Message-ID;
bh=lcj/Sl5qKl6K6zwFUwb7Flgnngl892pW574kmS1hrS0=;
b=nhVMQLmSh7/DM5PW7xPV4K/PN4iVY0a5OF4YYk2L7jgUq9hHQlckopxe82TaAr64
eVTcBhHHj9Bwtzkmuk88g4G5UUN8J+AAsd/JUNGoZOBS1OofSkuAQ6cGfRGanF68Ag7
nmmEjEi+JL5JQh//u+EKTH4TVb4zdEWlBuMlrdTg=
The "d" tag represents the domain that signs the email. In this case that would be our own domain, ses-example.com. This domain takes responsibility for the email, guaranteeing its integrity through the signature. The "h" tag contains a list of all of the headers of this email that are signed (and thus have their integrity guaranteed) by the signing domain. The "bh" tag is the result of a hash function applied to the email’s body (very useful to ensure that the content itself hasn’t been tampered with). Finally, the "b" tag is the actual signature itself, applied to the body hash and headers. If that checks out, then both the message body and all of the headers included in the "h" tag are considered to be authenticated by the signing domain.
That’s all very nice, but how does it stop an attacker?
The hashing and key encryption algorithms we use are well known, so surely anyone can generate their own key pair and calculate the signature themselves, right? In fact… this is actually true. Anyone can sign any email with a DKIM signature, the problem is getting ISPs to trust that that signature is ours and not the attacker’s. The key here is in the "s" and "d" tags of the signature. The "d" tag is our domain, and the "s" (or "selector") tag indicates which of our domain’s signing keys has been used for this particular email. It’s these two tags that help build the location of the public key in DNS and form the obstacle in the attacker’s path. In this signature’s case, any ISP that wants to validate our email will try to retrieve the public key from a record xtk53kxcy4p3t6ztbrffs6d54rsrrhh6._domainkey.ses-example.com ( <selector>._domainkey.<domain> ). An attacker can calculate hashes and signatures all they want but they won’t have permission to publish any key they control into our DNS, so they will never be able to compute a signature that has our domain as the "d" tag (and thus has its integrity guaranteed by us). DNS spoofing, it turns out, is not so easy to perform (although it has happened)! With only the public key visible in DNS, it is not computationally easy for any attacker to deduce the private part. Just in case, SES regularly rotates the keys, to thwart any such attempt.
Setting up DMARC can also signal ISPs to drop all emails that aren’t authenticated (via DKIM or SPF). If an attacker wants to impersonate our domain they can either put in a broken signature or no signature at all. In both cases, DMARC signals ISPs to quarantine (put in the Spam folder) or drop those emails. That is definitely a good step forward in dealing with phishing spam!
SES also offers other forms of authentication such as SPF, which are highly recommended and will further improve our security.
Next Steps
In the next blog entry, we will have a look at another email-related concept that is indirectly influenced by DKIM: deliverability.

DKIM Troubleshooting Series: Authentication Considerations

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/Tx2NCXUV8X3Z0WS/DKIM-Troubleshooting-Series-Authentication-Considerations

Hi, and welcome to another entry in the Amazon SES DKIM troubleshooting series. So far we have focused on technical issues, but now it’s time to take a step back and look at the bigger picture. Exactly why did we go to all this trouble in setting up DKIM for our domain?
My emails are signed and the signature validates. Does this mean I’m safe from spoofing attacks?
Even if all our email is DKIM signed and validated by all ISPs, this is no time to rest. The world is full of ethically dubious people who want to impersonate us and steal our customers, and DKIM is only step one in protecting ourselves.
So what exactly is DKIM doing to help us with this? The way this standard ensures the integrity of our emails is to calculate a hash of the message’s body and some of its headers, and then to digitally sign the hash. As long as the private key is kept secure, and the public key is accessible through DNS, the DKIM signature gives ISPs confidence that the domain that signs the message acknowledges its content through the signature. Let’s have another look at the DKIM signature to see exactly what we’re talking about:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=xtk53kxcy4p3t6ztbrffs6d54rsrrhh6; d=ses-example.com;
t=1366720445;
h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Date:Message-ID;
bh=lcj/Sl5qKl6K6zwFUwb7Flgnngl892pW574kmS1hrS0=;
b=nhVMQLmSh7/DM5PW7xPV4K/PN4iVY0a5OF4YYk2L7jgUq9hHQlckopxe82TaAr64
eVTcBhHHj9Bwtzkmuk88g4G5UUN8J+AAsd/JUNGoZOBS1OofSkuAQ6cGfRGanF68Ag7
nmmEjEi+JL5JQh//u+EKTH4TVb4zdEWlBuMlrdTg=
The "d" tag represents the domain that signs the email. In this case that would be our own domain, ses-example.com. This domain takes responsibility for the email, guaranteeing its integrity through the signature. The "h" tag contains a list of all of the headers of this email that are signed (and thus have their integrity guaranteed) by the signing domain. The "bh" tag is the result of a hash function applied to the email’s body (very useful to ensure that the content itself hasn’t been tampered with). Finally, the "b" tag is the actual signature itself, applied to the body hash and headers. If that checks out, then both the message body and all of the headers included in the "h" tag are considered to be authenticated by the signing domain.
That’s all very nice, but how does it stop an attacker?
The hashing and key encryption algorithms we use are well known, so surely anyone can generate their own key pair and calculate the signature themselves, right? In fact… this is actually true. Anyone can sign any email with a DKIM signature, the problem is getting ISPs to trust that that signature is ours and not the attacker’s. The key here is in the "s" and "d" tags of the signature. The "d" tag is our domain, and the "s" (or "selector") tag indicates which of our domain’s signing keys has been used for this particular email. It’s these two tags that help build the location of the public key in DNS and form the obstacle in the attacker’s path. In this signature’s case, any ISP that wants to validate our email will try to retrieve the public key from a record xtk53kxcy4p3t6ztbrffs6d54rsrrhh6._domainkey.ses-example.com ( <selector>._domainkey.<domain> ). An attacker can calculate hashes and signatures all they want but they won’t have permission to publish any key they control into our DNS, so they will never be able to compute a signature that has our domain as the "d" tag (and thus has its integrity guaranteed by us). DNS spoofing, it turns out, is not so easy to perform (although it has happened)! With only the public key visible in DNS, it is not computationally easy for any attacker to deduce the private part. Just in case, SES regularly rotates the keys, to thwart any such attempt.
Setting up DMARC can also signal ISPs to drop all emails that aren’t authenticated (via DKIM or SPF). If an attacker wants to impersonate our domain they can either put in a broken signature or no signature at all. In both cases, DMARC signals ISPs to quarantine (put in the Spam folder) or drop those emails. That is definitely a good step forward in dealing with phishing spam!
SES also offers other forms of authentication such as SPF, which are highly recommended and will further improve our security.
Next Steps
In the next blog entry, we will have a look at another email-related concept that is indirectly influenced by DKIM: deliverability.

DKIM Troubleshooting Series: Why is My Signature Not Validating?

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/Tx1OKJY188FDR9R/DKIM-Troubleshooting-Series-Why-is-My-Signature-Not-Validating

Hello and welcome to the fifth entry in the Amazon SES DKIM troubleshooting blog series. We have begun the task of setting up DKIM for a domain and overcome a great variety of DNS issues, to succeed in getting the signature to appear in our emails. This is when the next problem manifests itself: the DKIM signature we’ve worked so hard for is invalid.
My emails are now signed but I see a DNS validation error when viewing message headers
Finally, the so-far elusive DKIM-Signature header appears in our outgoing emails. But we cannot rejoice yet, because it looks like our hard-earned signature is not validating. We see a dkim=temperror message in our inbox. What could be happening now?
Occasionally, temporary DKIM validation errors by ISPs can appear, such as dkim=temperror. These could be due to a DNS glitch causing problems retrieving the public key record. The first thing to do is to confirm that our DNS is properly set up (see previous blog post). Next, we can try sending emails to addresses belonging to different ISPs. If only one ISP shows DKIM validation failures, that specific ISP could be having some trouble retrieving DNS records.
For our scenario, let’s suppose that half of our emails going to a certain ISP showed this header in our email client::

Authentication-Results: <ISP domain>; spf=pass (sender IP is 199.255.192.105) smtp.mailfr[email protected]amazonses.com; dkim=temperror header.d=ses-example.com; x-hmca=none

What we can do is send test emails to other major ISPs. If they regularly validate DKIM, it could be a problem with that specific ISP’s DNS resolver setup. If we see these kinds of errors appearing across all of the ISPs, we may want to confirm with our DNS provider whether our servers are constantly up, and serving correct results to all requests.
For this scenario, let’s assume that we have confirmed that our DNS is fine, and, after waiting a while, we’re no longer seeing any DNS validation errors with any ISP. We switch our production systems to use the new SES account and everything is going great… except that a number of our emails are displaying a very unusual signature invalidation message.
My emails are now signed but I see a body hash verification failure error when viewing message headers
We have confirmed that our DNS is fine, and we have begun sending emails to another ISP. We’ve returned to our original ISP and it appears that in the meantime they have fixed their DNS resolver issues and are now validating our signature. We switch our production systems to use the new SES account and… we’re in trouble again. All ISPs are reporting "body hash did not verify" errors. So what happened now?
Sometimes, when sending an email indirectly (from SES to a forwarding address or middleware software which then delivers it to an ISP), the intermediate layer alters the message body in some way. Since the body hash in the DKIM signature is calculated before the message exits the SES system, it obviously cannot account for changes en route.
We can try to send directly to an ISP and confirm whether we still see the issue. If the DKIM signature is validated there, then we look into any software we have that sits between SES and the destination domain that actually performs the DKIM validation.
For our scenario, let’s assume that our company had, for auditing purposes, a forwarding address that was capturing part of the traffic from our production systems. That address was configured to URL-encode some part of the message text, before resending it; that fact alone was enough to make the hash of the text invalid, thus compromising the signature. We disable the URL encoding in our software and try again. Finally, we see the DKIM validation successful message. Success!
Next Steps
With our signature now appearing in our emails and validating across all ISPs, we have come to the end of the technical part of the DKIM Troubleshooting series. The next entry will focus mainly on security issues, and we will find out exactly what DKIM does for us, and, equally important, what it doesn’t do.

DKIM Troubleshooting Series: Why is My Signature Not Validating?

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/Tx1OKJY188FDR9R/DKIM-Troubleshooting-Series-Why-is-My-Signature-Not-Validating

Hello and welcome to the fifth entry in the Amazon SES DKIM troubleshooting blog series. We have begun the task of setting up DKIM for a domain and overcome a great variety of DNS issues, to succeed in getting the signature to appear in our emails. This is when the next problem manifests itself: the DKIM signature we’ve worked so hard for is invalid.
My emails are now signed but I see a DNS validation error when viewing message headers
Finally, the so-far elusive DKIM-Signature header appears in our outgoing emails. But we cannot rejoice yet, because it looks like our hard-earned signature is not validating. We see a dkim=temperror message in our inbox. What could be happening now?
Occasionally, temporary DKIM validation errors by ISPs can appear, such as dkim=temperror. These could be due to a DNS glitch causing problems retrieving the public key record. The first thing to do is to confirm that our DNS is properly set up (see previous blog post). Next, we can try sending emails to addresses belonging to different ISPs. If only one ISP shows DKIM validation failures, that specific ISP could be having some trouble retrieving DNS records.
For our scenario, let’s suppose that half of our emails going to a certain ISP showed this header in our email client::

Authentication-Results: <ISP domain>; spf=pass (sender IP is 199.255.192.105) smtp.mailfr[email protected]amazonses.com; dkim=temperror header.d=ses-example.com; x-hmca=none

What we can do is send test emails to other major ISPs. If they regularly validate DKIM, it could be a problem with that specific ISP’s DNS resolver setup. If we see these kinds of errors appearing across all of the ISPs, we may want to confirm with our DNS provider whether our servers are constantly up, and serving correct results to all requests.
For this scenario, let’s assume that we have confirmed that our DNS is fine, and, after waiting a while, we’re no longer seeing any DNS validation errors with any ISP. We switch our production systems to use the new SES account and everything is going great… except that a number of our emails are displaying a very unusual signature invalidation message.
My emails are now signed but I see a body hash verification failure error when viewing message headers
We have confirmed that our DNS is fine, and we have begun sending emails to another ISP. We’ve returned to our original ISP and it appears that in the meantime they have fixed their DNS resolver issues and are now validating our signature. We switch our production systems to use the new SES account and… we’re in trouble again. All ISPs are reporting "body hash did not verify" errors. So what happened now?
Sometimes, when sending an email indirectly (from SES to a forwarding address or middleware software which then delivers it to an ISP), the intermediate layer alters the message body in some way. Since the body hash in the DKIM signature is calculated before the message exits the SES system, it obviously cannot account for changes en route.
We can try to send directly to an ISP and confirm whether we still see the issue. If the DKIM signature is validated there, then we look into any software we have that sits between SES and the destination domain that actually performs the DKIM validation.
For our scenario, let’s assume that our company had, for auditing purposes, a forwarding address that was capturing part of the traffic from our production systems. That address was configured to URL-encode some part of the message text, before resending it; that fact alone was enough to make the hash of the text invalid, thus compromising the signature. We disable the URL encoding in our software and try again. Finally, we see the DKIM validation successful message. Success!
Next Steps
With our signature now appearing in our emails and validating across all ISPs, we have come to the end of the technical part of the DKIM Troubleshooting series. The next entry will focus mainly on security issues, and we will find out exactly what DKIM does for us, and, equally important, what it doesn’t do.

DKIM Troubleshooting Series: Where is My Signature?

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/Tx2N41GP3TGZDLM/DKIM-Troubleshooting-Series-Where-is-My-Signature

In this blog series so far, we have seen various problems that could prevent us from having Amazon SES verify the DKIM setup for our domain, and some possible causes (and solutions). Having the DKIM domain verified with SES is only the first step of the process. We have yet to see a signed email, and, more importantly, to see what good it does us. Let’s continue on our route to improved email security and deliverability!
My domain is now successfully set up for DKIM. How do I verify that my emails really are signed?
We have finally been able to verify our domain, we have received the Amazon SES DKIM Setup Successful confirmation email, and we see the DKIM Verification Status: verified message in the SES console for our domain. We also made sure to enable DKIM for our domain in the SES console. So how can we double-check that everything is really in order?
To test DKIM signing, we send an email via SES to an email address that is under our control and view the email headers (Click ‘Show original’ in Gmail, ‘View message source’ in Hotmail or equivalent).
We are looking for a header named DKIM-Signature. The header should look like this:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=xtk53kxcy4p3t6ztbrffs6d54rsrrhh6; d=ses-example.com;
t=1366720445;
h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Date:Message-ID;
bh=lcj/Sl5qKl6K6zwFUwb7Flgnngl892pW574kmS1hrS0=;
b=nhVMQLmSh7/DM5PW7xPV4K/PN4iVY0a5OF4YYk2L7jgUq9hHQlckopxe82TaAr64
eVTcBhHHj9Bwtzkmuk88g4G5UUN8J+AAsd/JUNGoZOBS1OofSkuAQ6cGfRGanF68Ag7
nmmEjEi+JL5JQh//u+EKTH4TVb4zdEWlBuMlrdTg=
DKIM is now enabled and set up for my domain but my emails still aren’t signed
The SES console is showing that our DKIM setup is verified and that DKIM signing is enabled for our domain, ses-example.com. In our email client we see from the message ID header that the email was indeed sent by SES and that the “From” address does indeed belong to our domain. We also double-checked that we’re using the right AWS account. So why is SES not adding the signature to our emails?
Below are the message headers we see in our email client. Why is the DKIM-Signature header missing?

Delivered-To: [email protected]
Received: by 10.114.22.33 with SMTP id a1csp97368ldf;
Tue, 23 Apr 2013 05:34:07 -0700 (PDT)
X-Received: by 10.229.17.3 with SMTP id q3mr6499056qca.21.1366720447007;
Tue, 23 Apr 2013 05:34:07 -0700 (PDT)
Return-Path: <0000013e3[email protected]m>
Received: from a195-130.smtp-out.amazonses.com (a195-130.smtp-out.amazonses.com. [199.255.195.130])
by mx.google.com with ESMTP id g10si19883148qab.3.2013.04.23.05.34.06;
Tue, 23 Apr 2013 05:34:06 -0700 (PDT)
Received-SPF: pass (google.com: domain of [email protected]zonses.com designates 199.255.195.130 as permitted sender) client-ip=199.255.195.130;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of [email protected]zonses.com designates 199.255.195.130 as permitted sender) smtp.ma[email protected]amazonses.com;
Return-Path: [email protected]zonses.com
From: [email protected]
To: [email protected]
Subject: Testing DKIM
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Date: Tue, 23 Apr 2013 12:34:05 +0000
Message-ID: <[email protected]il.amazonses.com>
X-SES-Outgoing: 199.255.195.130
What we need to do is make sure that DKIM is enabled for the signing identity most relevant to the emails we are sending. If we have verified both our domain and an email address from that domain, settings at an email address level override those on a domain level. We need to either enable DKIM for all verified addresses from that domain (where we would like emails to be signed), or delete the email addresses in cases where the domain is also verified, to allow domain settings to take effect.
For the purpose of this scenario, let’s assume that we have verified the email address [email protected] We have also verified the domain ses-example.com and enabled DKIM signing for it. Because we didn’t remember to enable DKIM for our email address, all emails having [email protected] as the “From” address will not be DKIM-signed. To fix this we can either enable DKIM for [email protected] or delete the address completely, to allow domain-level settings to take authority.
For our scenario, we decide to enable DKIM signing for our sending address and try again. This time, the signature appears in emails in our email client. Does this mean we’re through? Not quite…
Next Steps
The next entry in the series will cover signature validation problems by presenting two possible problems we’ve seen our customers having that manifested themselves in signature invalidation with the ISPs.

DKIM Troubleshooting Series: Where is My Signature?

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/Tx2N41GP3TGZDLM/DKIM-Troubleshooting-Series-Where-is-My-Signature

In this blog series so far, we have seen various problems that could prevent us from having Amazon SES verify the DKIM setup for our domain, and some possible causes (and solutions). Having the DKIM domain verified with SES is only the first step of the process. We have yet to see a signed email, and, more importantly, to see what good it does us. Let’s continue on our route to improved email security and deliverability!
My domain is now successfully set up for DKIM. How do I verify that my emails really are signed?
We have finally been able to verify our domain, we have received the Amazon SES DKIM Setup Successful confirmation email, and we see the DKIM Verification Status: verified message in the SES console for our domain. We also made sure to enable DKIM for our domain in the SES console. So how can we double-check that everything is really in order?
To test DKIM signing, we send an email via SES to an email address that is under our control and view the email headers (Click ‘Show original’ in Gmail, ‘View message source’ in Hotmail or equivalent).
We are looking for a header named DKIM-Signature. The header should look like this:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=xtk53kxcy4p3t6ztbrffs6d54rsrrhh6; d=ses-example.com;
t=1366720445;
h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Date:Message-ID;
bh=lcj/Sl5qKl6K6zwFUwb7Flgnngl892pW574kmS1hrS0=;
b=nhVMQLmSh7/DM5PW7xPV4K/PN4iVY0a5OF4YYk2L7jgUq9hHQlckopxe82TaAr64
eVTcBhHHj9Bwtzkmuk88g4G5UUN8J+AAsd/JUNGoZOBS1OofSkuAQ6cGfRGanF68Ag7
nmmEjEi+JL5JQh//u+EKTH4TVb4zdEWlBuMlrdTg=
DKIM is now enabled and set up for my domain but my emails still aren’t signed
The SES console is showing that our DKIM setup is verified and that DKIM signing is enabled for our domain, ses-example.com. In our email client we see from the message ID header that the email was indeed sent by SES and that the “From” address does indeed belong to our domain. We also double-checked that we’re using the right AWS account. So why is SES not adding the signature to our emails?
Below are the message headers we see in our email client. Why is the DKIM-Signature header missing?

Delivered-To: [email protected]
Received: by 10.114.22.33 with SMTP id a1csp97368ldf;
Tue, 23 Apr 2013 05:34:07 -0700 (PDT)
X-Received: by 10.229.17.3 with SMTP id q3mr6499056qca.21.1366720447007;
Tue, 23 Apr 2013 05:34:07 -0700 (PDT)
Return-Path: <[email protected]zonses.com>
Received: from a195-130.smtp-out.amazonses.com (a195-130.smtp-out.amazonses.com. [199.255.195.130])
by mx.google.com with ESMTP id g10si19883148qab.3.2013.04.23.05.34.06;
Tue, 23 Apr 2013 05:34:06 -0700 (PDT)
Received-SPF: pass (google.com: domain of [email protected]zonses.com designates 199.255.195.130 as permitted sender) client-ip=199.255.195.130;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of [email protected]zonses.com designates 199.255.195.130 as permitted sender) smtp.ma[email protected]amazonses.com;
Return-Path: [email protected]zonses.com
From: [email protected]
To: [email protected]
Subject: Testing DKIM
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Date: Tue, 23 Apr 2013 12:34:05 +0000
Message-ID: <[email protected]il.amazonses.com>
X-SES-Outgoing: 199.255.195.130
What we need to do is make sure that DKIM is enabled for the signing identity most relevant to the emails we are sending. If we have verified both our domain and an email address from that domain, settings at an email address level override those on a domain level. We need to either enable DKIM for all verified addresses from that domain (where we would like emails to be signed), or delete the email addresses in cases where the domain is also verified, to allow domain settings to take effect.
For the purpose of this scenario, let’s assume that we have verified the email address [email protected] We have also verified the domain ses-example.com and enabled DKIM signing for it. Because we didn’t remember to enable DKIM for our email address, all emails having [email protected] as the “From” address will not be DKIM-signed. To fix this we can either enable DKIM for [email protected] or delete the address completely, to allow domain-level settings to take authority.
For our scenario, we decide to enable DKIM signing for our sending address and try again. This time, the signature appears in emails in our email client. Does this mean we’re through? Not quite…
Next Steps
The next entry in the series will cover signature validation problems by presenting two possible problems we’ve seen our customers having that manifested themselves in signature invalidation with the ISPs.

DKIM Troubleshooting Series: Your DKIM Status is Still Pending

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/TxUS3H7TUOCK6B/DKIM-Troubleshooting-Series-Your-DKIM-Status-is-Still-Pending

In this blog series, we are following the path of an engineer trying to set up DKIM for a domain, and examining various issues that can appear along the way. So far, we have been able to add to our DNS the records that Amazon SES gave us, and we confirmed that they resolve to the correct values. But we’re still having problems…
I can now successfully resolve all the DNS records but my domain’s DKIM verification status is still Pending
SES is still refusing to validate our setup, and our domain’s DKIM verification status still appears as Pending in the SES console. Occasionally, network glitches get in the way of DNS resolution. As long as the networking issues are resolved in time, they will not impact the process of setting up DKIM with SES. But we already waited for the 72 hours specified in the documentation and still haven’t received an Amazon SES DKIM Setup Successful confirmation email. We need to dive deeper than simply querying for TXT records in DNS and we need to check the health of our DNS system.
First, let’s make sure our domain has its authoritative name servers properly set up. Here’s how we retrieve the list of name servers for our domain in Linux using the dig command. We can see the list of name servers in the ANSWER SECTION of the dig output. We can also see how each name server has a properly configured IP address in the ADDITIONAL SECTION :

$ dig NS ses-example.com
; <<>> DiG 9.4.2 <<>> NS ses-example.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57753
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 12

;; QUESTION SECTION:
;ses-example.com. IN NS

;; ANSWER SECTION:
ses-example.com. 900 IN NS pdns6.ultradns.co.uk.
ses-example.com. 900 IN NS pdns1.ultradns.net.
ses-example.com. 900 IN NS pdns2.ultradns.net.
ses-example.com. 900 IN NS pdns3.ultradns.org.
ses-example.com. 900 IN NS pdns4.ultradns.org.
ses-example.com. 900 IN NS pdns5.ultradns.info.

;; ADDITIONAL SECTION:
pdns1.ultradns.net. 2974 IN A 204.74.108.1
pdns1.ultradns.net. 73009 IN AAAA 2001:502:f3ff::1
pdns2.ultradns.net. 1258 IN A 204.74.109.1
pdns2.ultradns.net. 73009 IN AAAA 2610:a1:1014::1
pdns3.ultradns.org. 2974 IN A 199.7.68.1
pdns3.ultradns.org. 71368 IN AAAA 2610:a1:1015::1
pdns4.ultradns.org. 688 IN A 199.7.69.1
pdns4.ultradns.org. 71368 IN AAAA 2001:502:4612::1
pdns5.ultradns.info. 2974 IN A 204.74.114.1
pdns5.ultradns.info. 71368 IN AAAA 2610:a1:1016::1
pdns6.ultradns.co.uk. 2974 IN A 204.74.115.1
pdns6.ultradns.co.uk. 85530 IN AAAA 2610:a1:1017::1

;; Query time: 63 msec
;; SERVER: 10.4.4.10#53(10.4.4.10)
;; WHEN: Tue Apr 23 12:21:56 2013
;; MSG SIZE rcvd: 468
After seeing that the name servers are properly set up for our domain, the next step is to verify that each of those servers can successfully resolve the domain keys. Here are example DNS queries directed against the name servers obtained in the previous step:

$ dig CNAME zxfo5z4dqr44uztwz5io2b4j4mwlrquj._domainkey.ses-example.com @pdns1.ultradns.net +short
zxfo5z4dqr44uztwz5io2b4j4mwlrquj.dkim.amazonses.com.

$ dig CNAME zxfo5z4dqr44uztwz5io2b4j4mwlrquj._domainkey.ses-example.com @pdns2.ultradns.net +short
zxfo5z4dqr44uztwz5io2b4j4mwlrquj.dkim.amazonses.com.
etc…

Common errors include record propagation issues or name server setup problems. Let’s assume that in our case, one of the name servers doesn’t respond to queries as it should:

$ dig CNAME xtk53kxcy4p3t6ztbrffs6d54rsrrhh6._domainkey.ses-example.com @pdns6.ultradns.net +short
$ dig CNAME zxfo5z4dqr44uztwz5io2b4j4mwlrquj._domainkey.ses-example.com @pdns6.ultradns.net +short
$ dig CNAME 5aws6ez5cxrf4hvt6w2qrip6pr4voupo._domainkey.ses-example.com @pdns6.ultradns.net +short

We fix our DNS setup and try again. Now we can see that our domain has properly configured name servers, and that each of them successfully resolves the CNAME records to the values indicated in the SES console. As indicated in the Developer Guide, we restart the DKIM verification process and now there is nothing in the way of SES verifying the setup for our domain. Indeed, a short while later, we get the confirmation email from Amazon, and we see our domain’s updated status in the SES console: DKIM is Verified! But the DNS issues we faced make us wonder…
My domain is now successfully set up for DKIM. But how does SES handle DNS errors caused by network glitches?
After seeing how fickle the network was in the previous step, we may be concerned about what happens when the records briefly become inaccessible.
SES repeatedly verifies that the DKIM CNAME records are still present in DNS and that the records resolve to the correct keys. SES does have degree of a tolerance to protect against network glitches, but if it repeatedly finds the records missing, it will disable DKIM signing for that domain’s emails. We will still be able to send, but our emails will no longer be signed.
The reasoning behind this is that if SES cannot resolve the DNS records, neither can ISPs. An email with a broken DKIM signature cannot be successfully associated with our domain, so ISPs may decide to send it to the Spam folder or even drop it all together in an effort to protect themselves and their customers against address spoofing and other fraudulent behavior. See the Developer Guide for more details on how SES revokes DKIM signing and how to reenable it.
Next Steps
So far, these DKIM troubleshooting blog posts have focused on various problems we can encounter when trying to validate our DKIM setup with SES. The next entries in the series will focus on debugging issues with the DKIM signature itself and the usefulness of DKIM in general.

DKIM Troubleshooting Series: Your DKIM Status is Still Pending

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/TxUS3H7TUOCK6B/DKIM-Troubleshooting-Series-Your-DKIM-Status-is-Still-Pending

In this blog series, we are following the path of an engineer trying to set up DKIM for a domain, and examining various issues that can appear along the way. So far, we have been able to add to our DNS the records that Amazon SES gave us, and we confirmed that they resolve to the correct values. But we’re still having problems…
I can now successfully resolve all the DNS records but my domain’s DKIM verification status is still Pending
SES is still refusing to validate our setup, and our domain’s DKIM verification status still appears as Pending in the SES console. Occasionally, network glitches get in the way of DNS resolution. As long as the networking issues are resolved in time, they will not impact the process of setting up DKIM with SES. But we already waited for the 72 hours specified in the documentation and still haven’t received an Amazon SES DKIM Setup Successful confirmation email. We need to dive deeper than simply querying for TXT records in DNS and we need to check the health of our DNS system.
First, let’s make sure our domain has its authoritative name servers properly set up. Here’s how we retrieve the list of name servers for our domain in Linux using the dig command. We can see the list of name servers in the ANSWER SECTION of the dig output. We can also see how each name server has a properly configured IP address in the ADDITIONAL SECTION :

$ dig NS ses-example.com
; <<>> DiG 9.4.2 <<>> NS ses-example.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57753
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 12

;; QUESTION SECTION:
;ses-example.com. IN NS

;; ANSWER SECTION:
ses-example.com. 900 IN NS pdns6.ultradns.co.uk.
ses-example.com. 900 IN NS pdns1.ultradns.net.
ses-example.com. 900 IN NS pdns2.ultradns.net.
ses-example.com. 900 IN NS pdns3.ultradns.org.
ses-example.com. 900 IN NS pdns4.ultradns.org.
ses-example.com. 900 IN NS pdns5.ultradns.info.

;; ADDITIONAL SECTION:
pdns1.ultradns.net. 2974 IN A 204.74.108.1
pdns1.ultradns.net. 73009 IN AAAA 2001:502:f3ff::1
pdns2.ultradns.net. 1258 IN A 204.74.109.1
pdns2.ultradns.net. 73009 IN AAAA 2610:a1:1014::1
pdns3.ultradns.org. 2974 IN A 199.7.68.1
pdns3.ultradns.org. 71368 IN AAAA 2610:a1:1015::1
pdns4.ultradns.org. 688 IN A 199.7.69.1
pdns4.ultradns.org. 71368 IN AAAA 2001:502:4612::1
pdns5.ultradns.info. 2974 IN A 204.74.114.1
pdns5.ultradns.info. 71368 IN AAAA 2610:a1:1016::1
pdns6.ultradns.co.uk. 2974 IN A 204.74.115.1
pdns6.ultradns.co.uk. 85530 IN AAAA 2610:a1:1017::1

;; Query time: 63 msec
;; SERVER: 10.4.4.10#53(10.4.4.10)
;; WHEN: Tue Apr 23 12:21:56 2013
;; MSG SIZE rcvd: 468
After seeing that the name servers are properly set up for our domain, the next step is to verify that each of those servers can successfully resolve the domain keys. Here are example DNS queries directed against the name servers obtained in the previous step:

$ dig CNAME zxfo5z4dqr44uztwz5io2b4j4mwlrquj._domainkey.ses-example.com @pdns1.ultradns.net +short
zxfo5z4dqr44uztwz5io2b4j4mwlrquj.dkim.amazonses.com.

$ dig CNAME zxfo5z4dqr44uztwz5io2b4j4mwlrquj._domainkey.ses-example.com @pdns2.ultradns.net +short
zxfo5z4dqr44uztwz5io2b4j4mwlrquj.dkim.amazonses.com.
etc…

Common errors include record propagation issues or name server setup problems. Let’s assume that in our case, one of the name servers doesn’t respond to queries as it should:

$ dig CNAME xtk53kxcy4p3t6ztbrffs6d54rsrrhh6._domainkey.ses-example.com @pdns6.ultradns.net +short
$ dig CNAME zxfo5z4dqr44uztwz5io2b4j4mwlrquj._domainkey.ses-example.com @pdns6.ultradns.net +short
$ dig CNAME 5aws6ez5cxrf4hvt6w2qrip6pr4voupo._domainkey.ses-example.com @pdns6.ultradns.net +short

We fix our DNS setup and try again. Now we can see that our domain has properly configured name servers, and that each of them successfully resolves the CNAME records to the values indicated in the SES console. As indicated in the Developer Guide, we restart the DKIM verification process and now there is nothing in the way of SES verifying the setup for our domain. Indeed, a short while later, we get the confirmation email from Amazon, and we see our domain’s updated status in the SES console: DKIM is Verified! But the DNS issues we faced make us wonder…
My domain is now successfully set up for DKIM. But how does SES handle DNS errors caused by network glitches?
After seeing how fickle the network was in the previous step, we may be concerned about what happens when the records briefly become inaccessible.
SES repeatedly verifies that the DKIM CNAME records are still present in DNS and that the records resolve to the correct keys. SES does have degree of a tolerance to protect against network glitches, but if it repeatedly finds the records missing, it will disable DKIM signing for that domain’s emails. We will still be able to send, but our emails will no longer be signed.
The reasoning behind this is that if SES cannot resolve the DNS records, neither can ISPs. An email with a broken DKIM signature cannot be successfully associated with our domain, so ISPs may decide to send it to the Spam folder or even drop it all together in an effort to protect themselves and their customers against address spoofing and other fraudulent behavior. See the Developer Guide for more details on how SES revokes DKIM signing and how to reenable it.
Next Steps
So far, these DKIM troubleshooting blog posts have focused on various problems we can encounter when trying to validate our DKIM setup with SES. The next entries in the series will focus on debugging issues with the DKIM signature itself and the usefulness of DKIM in general.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close