Problems with SPUtility.SendEmail in custom timer job

Last week I ran into a strange problem. I wrote a custom timer job which will send reminder emails to employees who haven't finished their task after a certain time.
Problem(s):
Sending emails is easy, by using the SPUtility.SendEmail function. Well, at least it should be easy. There are a lot of code samples, so search around for some if you need it. However, again I ran into a SharePoint problem. This function returns a boolean value and gave me 'false' all the time. I tried to use the ordinary mail method of System.Net.Mail. There I got an error about "Message rejected as spam by Content Filtering". Some research of the IT department on Exchange did not solve this problem.
Well, I went back to the SPUtility.SendEmail function. I turned out that using the StringDictionary gave some problems as well as using HTML tags. Using plane text and one of the other overloads that doesn't use the StringDictionary results in a successful send action. But I needed a formatted message (sending some links).
The LOG files gave some extra information on the 'false' action. And yes, it shows why it didn't send the messages: 550 5.7.1 Message rejected as spam by Content Filtering.
Solution:
The solution I found (here) was relatively easy. Bypassing the content filter for a specific email address (or even sender domain). To do this, you need to resort to the Exchange shell (EMS) to manage it.

1. Click on Start > All Programs > Microsoft Exchange 20xx > Exchange Management Shell. Note, this works for at least Exchange 2007 and 2010 versions.
2. Create the bypass for the 'from' email address you use when sending the email from a timer job:
   Set-ContentFilterConfig -BypassedSenders somebody1@mycompany.com, somebody2@mycompany.com

Note: You need to realize that spammers can spoof the 'from' address and this would allow spam to get thru.

So, after all, it was not really a SharePoint problem, but an Exchange 'problem'.

Reference: http://exchangepedia.com/blog/2007/01/exchange-2007-content-filter-whitelist.html

Value does not fall within the expected range

Currently working on SharePoint and yep, running into strange problems and errors. A better name will be ShareProblems or SharePointless. However, just kidding a bit. But seriously, I run into the following situation:
Situation:
Running a webservice outside SharePoint which will receive data from a webform (on another server) in JSON format. The received data will be saved in a SharePoint list by using the client side object model. So far so good. The initial test where run by the administrator account (used for the installation and configuration of SharePoint). It worked fine. Because I have to run a workflow on 'new item created' on the SharePoint list, I needed a 'normal' account. The admin and service accounts are not allowed to start workflows. So, new AD account defined, gave the appropriate rights and voila... uh, not really.
Problem: 
Part of the code:

ListItemCreationInformation lici = new ListItemCreationInformation();
ListItem item = list.AddItem(lici);

item["Title"] = HttpUtility.UrlDecode(name);
item["Category"] = (categorie == "0") ? 15 : int.Parse(categorie);
item["Street"] = HttpUtility.UrlDecode(street);
item["Postal_x0020_Code"] = HttpUtility.UrlDecode(postalcode);

item.Update();
_clientContext.ExecuteQuery();

I got the return message: Value does not fall within the expected range.
The callstack was something like this:

at Microsoft.SharePoint.Client.ClientRequest.ProcessResponseStream(Stream responseStream) at Microsoft.SharePoint.Client.ClientRequest.ProcessResponse() at Microsoft.SharePoint.Client.ClientContext.ExecuteQuery() at DnmWebServices.MessagingService.SendRtvRequest(String name, String category, String street, String postalcode) in c:\inetpub\wwwroot\DnmWebServices\App_Code\MessagingService.cs:line 128

Line 128 in my case points to the _clientContext.ExecuteQuery.
Solution(s):
It seems there can be several causes.
1). Use of invalid field name. You need to use the internal field name! However, that was not the case in my situation.
2). Change the List View Lookup Threshold value of the web application. Default value is 8, I changed it to 20 and big surprise: it worked! Thanks to this post.
Note: My item has some lookup fields some of which some have more than 8 items.
Little conclusion: So it seems that when using (one of) the system admin accounts, this list view lookup threshold is ignored in one way. By using non-system admin accounts, it can be a show stopper.
Steps to edit this value:

• Go to Central Administration > Application Management > Manage web applications
• Select the appropriate web application (in my case the SharePoint - 80)
• In the ribbon bar, select General Settings > Resourse Throttling
• Search for the List View Lookup Threshold and change the value to 20.