How does an email get delivered?

The basics
When asked for which purposes people most frequently use their computer, then the response often contains the term “email”. Yet in my experience most people have no clue how this digital letter gets from person X to person Y. This article will sketch a rough image of how email works.

Person X types an email in his/her mail client (to for example bob@example.com). This can either be a web based or locally installed client. After pressing the “send” button, the email will be sent towards an outgoing mail server (MTA). This server will queue the mail, and lookup the location where this mail should be delivered by using a DNS server. Imagine the DNS server as a catalog of the internet. It contains (or can lookup) the network locations of a certain domain name (like example.com). The MTA will ask the DNS server to give the location of the mail server (mx record) for bob@example.com.

The architecture behind microsoft.com

Jeff Alexander blogged about the setup behind microsoft.com. It got the slashdot effect, and his blog is apparently (temporarily?) suspended. You can find the blog post below, as I dug it from out of the google caches.

Microsoft.com: What’s the story?
If you’ve ever wondered how microsoft.com uses our technology then read on. I recently came across some good information from the folks over at the Operations team at Microsoft.com. The thread basically talks about how we use IIS, Firewalls and Windows Server 2008. I think as we come up to launch next year it’s a really good and quick insight into what they do and how they do it. So enjoy the reading and let me know what you think..Pretend I’ve asked about how they protect our sites…

At this point we still don’t use firewalls for MS.COM sites and don’t have any plans on the books to put them in place. Here is the short answer as to why:

“Yet another NMAP tutorial”

Check out this article on EthicalHacker. It’s a rather nice summary of the possibilities of nmap. Personally I found the description on the different scans interesting. Have fun reading up…

OpenWRT: ‘pushing’ the linksys wrtg54 on step further

A while back a wrote a small note about linux for embedded devices. Yesterday I put that to the test by installing OpenWRT on my Linksys WRTG (v2.2).

The installation was as smooth as ice: No problems at all! I first installed the latest stable. This was simply done by logging into the existing webinterface of my Linksys WRTG, and doing a firmware upgrade with the specific image for my linksys.

A note here: Read the common mistakes, like for instance this important one.

“You need to convert the bin (eg. openwrt-wrt54g-squashfs.bin) file to a trx file before reflashing” WRONG!!!

The openwrt-brcm-squashfs.trx is a generic trx file that will work on any supported broadcom platform. The openwrt-wrt54g-squashfs.bin is just “bin header + openwrt-brcm-squashfs.trx’, the bin header just contains the firmware version number and what models the firmware can be loaded on; the bin header is only used for verification before writing the trx data to the flash. The mtd utility writes the given file to flash without verifying it; use one of the openwrt-brcm-squashfs.trx when using mtd. Converting the openwrt-wrt54g-squashfs.bin file back to a trx is just plain ignorant.