Monday, September 19, 2011

Emails to Hotmail lost

I manage the newsletters/email list for a non-profit organization. The organization has it own website and mail server hosted on a shared server with a hosting company. We use phplist to manage the organization's email list. Everything was working fine and email subscribers were receiving emails from our mailing list.
One day, we noticed that users who have subscribed with a hotmail or windows live email id stopped receiving emails. We checked our mail logs and confirmed that the mails were transmitted and there was no bounce back from the hotmail service.
After some research I found out that we were not alone and several folks using shared hosting had mail delivery issues with the hotmail/windows live service. Apparently Microsoft's spam filtering mechanism thought our email was spam. Doing a Google on the above issue turned out quite a few posting with plenty of Microsoft bashing.
I decided to followup with Microsoft and opened a support ticket. While on the support site I came across the guidelines page that lists the guidelines for proper delivery of email to Hotmail/live accounts. Basically you have to create Publish Sender Policy Framework (SPF) record for the domain the email will be send from. Here is a good reading on SPF.
Submit a SenderId ticket to Hotmail from Submit new Sender ID Records to Windows Live Hotmail.
Once your submission is approved, the emails from your domain will be delivered to the Hotmail users.


Tuesday, September 6, 2011

Html.ActionLink() outputting current URL parameters

In my MVC application I was using Html.ActionLink() to generate URLs for the menu items on the site navigation. I had a few menu items like "Locations", "Subscribers", "Categories" and "Deals". The URLs for these items where "http://www.mysite.com/Locations", "http://www.mysite.com/Subscribers", "http://www.mysite.com/Categories" and "http://www.mysite.com/Deals" respectively. The links were generated using the following code:

                <ul id="menu">
                    <li>@Html.ActionLink("Home", "Index", "Home")</li>
                    <li>@Html.ActionLink("Locations", "Index", "Location")</li>
                    <li>@Html.ActionLink("Subscribers", "Index", "Subscriber")</li>
                    <li>@Html.ActionLink("Categories", "Index", "Category")</li>
                    <li>@Html.ActionLink("Deals", "Index", "Deals")</li>
                </ul>

The URLs for the menu items were generated as expected. The "Subscribers" and "Deals" pages supported pagination meaning, we can pass a page number to the URL like http://www.mysite.com/Subscribers/Page/2 and the page would display a subset of the subscribers data instead of all the subscribers from the database.While testing the page, I noticed that the URLs for the Subscribers and Deals were displayed as "http://www.mysite.com/Categories/Page/2" and "http://www.mysite.com/Deals/Page/2" instead of just "http://www.mysite.com/Categories" and "http://www.mysite.com/Deals" respectively. But I wanted the menu item URL to always point to the Categories and Deals URLs irrespective of the current page parameters. After doing some research I figured out this can be accomplished by passing the "ActionName" parameter as an empty string for the ActionLink(). So here is the updated code.
                    <li>@Html.ActionLink("Home", "Index", "Home")</li>
                    <li>@Html.ActionLink("Locations", "Index", "Location")</li>
                    <li>@Html.ActionLink("Subscribers", string.Empty, "Subscriber")</li>
                    <li>@Html.ActionLink("Categories", "Index", "Category")</li>
                    <li>@Html.ActionLink("Deals", string.Empty, "Deals")</li>
                </ul>

So now the URLs in the menu items remain the same irrespective of the current page URL parameters.

Friday, May 1, 2009

UrlRewritingNet default redirects

We were using UrlRewritingNet on one our site that hosts marketing landing pages. Our marketing URLs are in the format "http://mydomain/campaign/123456" where the "123456" is a PIN associated with a particular user. Since we can't create a seperate landing page for each user, we setup a redirect rule like this:

With the above rule in place, any page with a PIN at the end of the URL will be rewritten as http://mydomain/campaign/default.aspx?PIN= . So one page can handle an entire campaign without the need to create a seperate page for each user. This worked very well and we were doing multiple campaigns successfully.

Note here that the campaign URLs do not have a file extension and so we had setup IIS to send all web requests to ASP.Net as detailed in the URLRewritingNet documentation. Since IIS was sending all web requests to ASP.Net, we have to set up the defaultPage property in the URLRewritingNet configuration to "default.aspx".

One issue we faced here is that we couldn't access the home page of the web site. When we try http://mydomain/ our request would time out after a long wait. But if we type http://mydomain/default.aspx it renders just fine. This happens only on our QA and PROD web sites. Our DEV site with the same setting worked without a glitch. The difference between these environment is that the dev server was a standalone server and the QA and PROD servers were load balanced with a BigIP(f5).

Our QA and PROD web servers in the DMZ were using a non standard http port (for security reasons) for communications between the f5 and the individual servers. Later, we found out that when we try to access http://mydomain/ the URLRewritingNet was redirecting the request either to http://mydomain01:45555/default.aspx or http://mydomain02:45555/default.aspx depending on which server received the request. Since the server specific URL is only accessible inside our DMZ, the request to the default pages were failing.

After trying different settings with URLRewritingNet config and some other, we figured out that by setting the defaultpage property to "", we resolved the issue.

Wednesday, August 22, 2007

Organization Hierarchy not displayed in sharepoint user profile page

Recently, I was trying to populate the sharepoint user's profile properties from our HR database using BDC. The profile properties were populated after I configured the BDC and ran a full import. But when I viewed the user's profile on the profile page, the organization hierarcy displayed only one level of the hierarchy. After some research, I found out that the Manager field has to be populated using the syntax DOMAINNAME\USERID instead of just USERID. So I changed my BDC to return the manager field using the above syntax and now I can view the more than one level in the organization hierarchy.

The DOMAINNAME\USERID is one of the three (email and LDAP syntax being the other) different forms the manager field can be populated. I decided to use this format due the kind of data available in my HR database. Remember, if you use only the USERID of the manager in the manager field, you will see only one level of hierarchy in the user's profile page.