Skip to main content

Invalid DKIM Signature for Some Mail

As of 2023-07-26 FeedMail messages sent via AWS SES have an invalid feedmail.org DKIM signature. This may result in messages ending up in your spam folder. This is an ongoing issue and updates will be posted here as they are available.

2023-09-25 We have issue an update that should avoid SES re-formatting signed fields. This is a workaround but should result in valid signatures.

Who is affected?

This is unlikely to affect most of our users for the following reasons:

  • 97% of our mail is sent by us directly, not via AWS.
  • This mail still has a SPF-verified sending IP.

However this may still affect users because spam filters may consider these messages less "good" than they would have been with a valid DKIM signature.

The most notable Inbox Providers affected by this are Apple and Microsoft. FeedMail uses AWS SES for these providers as they reject all messages from our network provider. However other smaller providers may also have a portion of their messages sent via AWS SES. 

What to do if you are affected?

If you are affected the best option is to add a rule to ensure that messages from feedmail.org are not set to spam. The process for doing this depends on your email provider.

If you have other concerns please contact FeedMail Support.

Technical Description

Background

FeedMail uses DKIM to apply a digital signature to outgoing email. This allows users who receive the email to know that the message is from FeedMail (not an impersonator) and hasn't been altered.

FeedMail uses a multi-pronged approach to delivering email. We have a "direct send" approach that we use for inbox providers that we have built a good reputation with. These providers trust feedmail.org and accept our email reliably. So FeedMail directly connects and delivers email to these providers. This provides maximum privacy, performance, control and lowest cost. However some email providers are much pickier. Most commonly they have blacklisted our IP range and reject every email even though it is coming from feedmail.org. In order to resolve this issue we proxy these messages via AWS SES. This allows us to use an IP address with a higher reputation for a small fee. The problem exists with these proxied emails.

Header Munging

The problem appears to be around a single header. FeedMail sends the following header in our outgoing messages:

Reply-To: "FeedMail Support" <contact-project+kevincox-feedmail-support@incoming.gitlab.com>

AWS SES has recently started changing this to:

Reply-To: FeedMail Support <contact-project+kevincox-feedmail-support@incoming.gitlab.com>

While this change is semantically unimportant it is enough to break our DKIM signature. Since the message has been altered it does not validate and can't be confirmed as coming from us.

Who is at fault?

We believe that AWS SES is behaving wrongly here. Their documentation clearly states which headers may be altered by SES and therefore can't be signed. Reply-To is not on their list so altering it is breaking their contract of preserving the DKIM signature.

Possible Solutions

The simplest workaround would be to skip signing the Reply-To header. However since this header may be used by users to contact support it could be a valuable phishing vector. So it would be best not to skip signing this header. However if SES remains broken we may need to stop signing it.

Another possible workaround is to try to match SES's format in hopes that they don't alter it if it is already in that format. this is possible but would require altering the libraries that we use to generate the email messages and would open up a game of chasing SES's header encoding format.

One last option is moving off of SES. This is a difficult option because SES is very inexpensive and pay-as-you-go. This is important to FeedMail as we only send a small volume of mail via SES and minimum monthly feeds would blow our budget. We aim to be low cost so keeping our mail sending cheap is important. Furthermore SES is one of the few providers that allow us to sign our messages before submission. This improves security by not allowing them to impersonate us with our DKIM key. Other than this bug they have been a very good provider and we would prefer not to have to move off. However we have experimented with various providers in the past and it is very easy for us to switch. So if necessary we will find an alternate provider.

What we are doing to resolve this issue?

Unfortunately AWS has no unpaid support, even for bugs in their services. We have tried to make them aware of this issue but lack any official channels to do so.

If there is no movement on their side we will explore some solutions that can be done from our side as described in the above section.

Labels:

Comments

Post a Comment

Popular posts from this blog

DNS Outage

From 2024-08-26 19:46 to 2024-08-27 11:21 UTC FeedMail had an outage. Until 2024-06-26 20:34 FeedMail was completely down. For the remainder of the outage most emails not sent. It is expected that no feed updates were lost during this outage. Updates would only be lost if they were only present on the feed within the 50min of total outage. Most feeds ensure that updates are present for days so this would not be an issue. Notifications have been delayed and should be sent by 2024-08-27 12:31. This may take longer if your mail provider applies limits and FeedMail needs to retry delivery at a later time. Update : All delayed notifications have been sent successfully. Timeline All times are in UTC . 2024-08-26 19:46 Start FeedMail goes down.   19:53 Detection Automated monitoring reported that feeds were not being checked. 20:34 The Database IP was hardcoded, restoring most functionality. 2024-08-27 11:21 Resolution FeedMail was switched external DNS. 11:24 Schedule of ...
Post a Comment
Read more

Digests are now Supported for Owner-Paid Feeds

Owner-paid feeds allow feed publishers to provide FeedMail to their subscribers at no cost. For example the FeedMail Blog is an owner-paid feed. Up until now digest subscriptions were not covered by owner-paid plans. Subscribers could select a digest but they would have to pay for the subscriptions themselves. Digests are now fully supported under owner-paid plans. For users: The owner-paid feeds in your digests no longer count towards the cost of the digest. For publishers: Users will now be able to receive your feed as a digest or included in one of their existing digests. You will be charged one credit for each digest issue containing items from your feed (no matter how many items from your feed are in that issue). Notably this cost will never be more than real-time subscriptions would be.
Post a Comment
Read more

Changes to Billing for Multiple Simultaneous Updates

This change may result in increased credit usage for non-digest subscriptions. Am I Affected? Digest Subscriptions are unaffected . Owner-paid Feeds are unaffected . Frequently updating real-time subscriptions are affected . If you have questions regarding your specific subscriptions please contact FeedMail support . Background FeedMail pricing has always been 1 credit per email notification. However in practice FeedMail would charge at most 1 credit every time a feed was checked, even if there were multiple new items on that feed and multiple emails were sent. In other words FeedMail sometimes undercharged users. Going forward, this billing error will be corrected, which may result in higher credit usage for feeds that were previously undercharged. Correcting this issue is essential to preventing abuse, ensuring long-term sustainability, and maintaining fair pricing. Multiple updates are a rare occurrence. It usually happens on on feeds that update very often (faster than once every 5...
Post a Comment
Read more