Outlook keeps asking for password

At work, we are required to change our passwords every 8 months. It’s company policy, you there’s no way around it. Every time this happens, I have problems with Outlook after that password change. When my Outlook desktop application in Windows starts, an old school grey popup appears that is asking for my password. The “Remember credentials” checkbox never seems to work.

Anyways, after this password change, the popup almost immediately pops up again. And again. And again. And again. Until up to the point when I desperately call by IT colleagues.

Today I found out that my account is simply blocked. After a attempts, logging in with the wrong password, the account is automatically disabled.

The thing is, I also use the Android Outlook app, to be able to read e-mails on my phone. After I change my windows credentials, I know I should also change this in the app. Except, I couldn’t find a place where to do this. The only option in my Exchange settings is to “reconfigure” the account, whatever that means.

So, my Android app probably keeps hammering the exchange server with wrong credentials, hence my account is locked.

Today I managed to get into the credentials settings in the app; I don’t know how though. I pressed the “reconfigure account” button, but nothing seemed to happen in the first place. Then after a while, it suddenly said, ok, you should enter your password. Which didn’t work in the first place of course, because my account was locked (again!).

So, I still don’t know what the right procedure is exactly, but I can save myself a lot of time googling for a solution. Because when your account is simply locked, I guess no solution on Google will work anyways.

Network share cache


At work we have an iOS app that is communicating with a windows application. In fact, it communicates to a WAMP (Apache on Windows) server. On the first request, data is being sent, which is then passed to our Windows application. This application creates a PDF report on a network share. This report will then be fetched by the iOS app.

We had a problem though with fetching the content after the process was done creating the PDF. The file was there, but Apache didn’t see it yet, so it returned a 404. We created a workaround by requesting the URL in a for loop to see when the file was available, and then the creation process would end. In the Apache access logs we could see that after retrying for about 10 seconds, the file finally became available to Apache.

Network cache

The webserver is running on a different server as the fileserver. The file is being saved to a location on the file server. So after testing and debugging for a while, we searched how we might improve the performance of the network.

Finally we found this article by Microsoft, which documents some configuration settings that can be set in the registry. I didn’t think this would help, but we tried it anyways.

To my great surprise: it did work! Now the file was already present at the first request that was made by the Apache web server. So our performance increased 10 times.

The settings we added to the registry were:

FileInfoCacheLifetime: set to 1 sec
DirectoryCacheLifetime: set to 1 sec
FileNotFoundCacheLifetime: set to 1 sec

We added this settings on the client machine, so in our case the webserver that is reaching out to the file server. A reboot was not required. The next time we checked, the response was a lot quicker.

So this was a great improvement. We’re not sure yet what the cost of this change is, but since the servers are running on the same virtual platform, I don’t think there will be any downside to this setup. Maybe when you’re on a slow network these settings could make things worse. But for us this really helped.

Hopefully for you too.

Forward incoming mail using Amazon Services and Lambda

In this post I’ll try to explain how I used Amazon to forward our incoming mail to an e-mail address like gmail.

Update 25 jan 2017: I seem to have missed some comments on this post, because they ended up in my spam folder :-(. Personally I don’t use my own solution as described here anymore. I think we switched to namecheaps forwarding service after all. Anyways, I couldn’t help myself but googling a bit on this subject, and it seems somebody else came up with the idea of using lambda to forward e-mail. I haven’t tried it but this project has nice little green icons that says it has been tested, so it must be better than what I did here.

Update 16 feb: Updated the lambda script thanks to Chris in the comments :-)

Next day update: Forwarding mime coded mails didn’t show up too well in my mail client. Of course I was testing with plaintext first ;-). Also I found this github page, describing pretty much the same as this post, although they still use S3 objects which I find redundant. I updated my Lambda script. It now sends a raw message, copying the Content-Type and Content-Transfer-Encoding headers from the original headers. This seems to display much better :-)

Use case

Say you have a domain specifically for e-mail campaigns. To setup this domain as a whitelabel domain in Sendgrid, or whatever third party you use, you must probably verify the send address. To do so, you must be able to receive mail.

Maintaining a mailserver is a pain in the ass though, with all those evil spammers around. So we happily leave that to companies who are must better in that. On the other hand, we don’t want to pay for each campaign just to receive this stupid verification link. Forwarding e-mail seems like a nice solution.

However, we found that the services at namecheap, which included e-mail forwarding, isn’t always that reliable. So we switched to Amazon for our DNS services. Wouldn’t it be nice to use Amazon to receive and handle our e-mail as well? Could Amazon simply forward e-mail?

Well, turns out it can forward e-mail, but not with a one-click install. Here’s how I did it.


I used SES for incoming e-mail (and eventually outgoing as well). SES pushes the mail to SNS. And SNS pushes the notification with a Lamda function to e-mail with a little javascript.

I found this post on the amazon forum, but this guy used a s3 bucket to pull the e-mail from. I don’t want to store the mail in a bucket; I want to forward it immediately.

So I changed the script to fetch the information from the SES message directly. After I had fixed the scripts, permissions, etc it turned out that SES doesn’t send the actual contents of the e-mail message to the lambda script. But if you push the message to SNS, then the SNS message does contain the contents. So therefore I push to SNS, and let SNS push to lambda.

Setup SES

SES is Amazons Simpel Email Service. It is able to send and receive mail. But you need to verify your domain first, as well as the Email addresses you are going to use. At first I thought I only needed to verify the e-mail address that I use in the FROM field, but if you are in sandbox mode, you will also need to add the TO address.

Just add it exactly the same way, by pushing the “Verify a new email address” button, and enter the e-mail address that will be receiving the forwarded mails. Of course you can also have your SES account un-sandboxed, but actually I like this extra layer of security.

After you verify your e-mail addresses, you have to setup the Email receiving part. You have to make sure that your domain is configured correctly to let Amazon receive the mail. If you use route53 (which I think you should), Amazon can configure this automatically for you.

When that’s all done, you can create a rule set to receive the mails. But first, we need to setup the lambda function, and then the SNS service.

Setup Lambda

The lambda function can be created in python, node.js and java. I already had a node.js script to start with, so I changed that a bit to fit my needs. Just go to the lambda section and follow directions on the screen until the part where you can ‘Create a Lambda function’.

In my case it first came up with a screen ‘Select blueprint’, but you can just skip that. Then fill in the name, description and runtime (Node.js). And then use this script, but change it a bit to fit your needs.

At handler I used index.handler, and at Role I used the basic execution role. You will need this role later on to add permissions.

Now you could run a test with SNS, but the example test data doesn’t contain an e-mail message, so this won’t work very well. It should not come up with any errors though.

The downside of this forward is that you cannot see the original “to” address in your e-mail client directly. It is sent in the X-Original-To header though, so you could use this to build a filter or something like that.

Setup SNS

Now go to the SNS service to create a Simple Notification Service. First you create a topic that you name ‘ForwardEmail’ or whatever you like.

Then on the navigation on the left you can click on “topics” which gives you an overview of the topics. Click on that geeky looking ARN name. Now you should be able to create a subscription for this topic.

Here you select AWS Lambda as protocol, and then select the endpoint you created in the previous step.

So now you have a notification service that forwards notifications to the lambda script. You should note that the lambda function is only suitable for e-mails though, so if you connect another Amazon service to this SNS things will probably break.

Setup SES again

Now back to the SES configuration again. Make sure both the forwardFrom and forwardTo address are verified at the “Email addresses” section.

Now create the rule set at Email Receiving.

I setup the first action as SNS, selecting my ForwardEmail SNS. Then as second action I added Stop Rule Set, but I’m note sure if this is mandatory.

Test your setup

When I was testing my Lambda script at the Lambda service section, I basically had two problems, after I weeded out all the bugs in my script. First I got an e-mail verification error, because I didn’t know I had to verify the receiving e-mail address as well.

Second, I received an error, something like this:

User arn:aws:sts::167718239101:assumed-role/lambda_basic_execution/awslambda_724_20160203104053770' is not authorized to perform ses:SendEmail' on resource `arn:aws:ses:us-west-2:167718239101:identity/forwarder@email-service-support.com'

Turns out that Amazon also has a very sophisticated permission management thing. To fix this, go to IAM under Services (Security & Identity). At the dashboard you can see that you have Roles, my dashboard says Roles: 1. Click on it and you will see an overview of your roles. Here you will also see lambda_basic_execution.

Click on it, and at Inline policies click on “Create Role Policy”. Then add this policy:

That’s it. At the service CloudWatch you should be able to see the logging of your lambda script. Also you should probably reduce the retention, because if you keep your logs forever I think Amazon will make you pay for it.

Hope this helps you. I am no Amazon expert whatsoever, so I’m afraid this is all I can tell you at the moment :-).

Solution to: Sender ID (PRA) Not Permitted

I knew that Microsoft’s Sender ID wasn’t a perfectly implemented solution, but I never investigated why. Now I know. Because despite using a dedicated company to send our mails through (SendGrid at this moment), we still got a bounce saying “Sender ID (PRA) Not Permitted”.

The reason is that Microsoft uses the SPF policies wrong. You can read all about it at the SPF vs Sender ID article. From what I understand from this article, all you have to do is add an extra TXT record to the DNS of your domain, with the contents “spf2.0/pra”.

Microsoft’s Sender ID Framework SPF Record Wizard recommends “spf2.0/pra ?all” though, so I went with that.

Of course you need to have already working SPF records for this to work.