One of the best tools I've used over the years to learn something new is to go through the entire process of how it happens in EXTREME detail from start to finish. In today's post, I'll walk you through how a typical corporate email is sent and ultimately reaches its destination in as much (relevant) detail as I can. For example, I will explain where a DNS query is used but will not discuss the intricacies of how DNS works and what would happen if the primary DNS server didn't respond, etc. in order to stay on topic.
In order to create the most relevant information I can, I'll try to keep things general by avoiding any specific applications.
1) A user sitting a PC in a corporate network types an email from wiley@acme.com into their mail client to bob@contoso.com and clicks 'send'.
2) The mail client will attempt to send the mail to the preconfigured mail server. Most often, the mail server is configured with a DNS name.
3) The PC looks in its DNS cache for the mail server. If the IP is not in cache, the PC send a DNS query to its primary DNS server to obtain the IP address of the mail server.
4) Now that the PC has the IP of the mail server, it will start to think about making a connection to it. Therefore, it looks at its IP address and subnet mask to see if it is in the same subnet as the mail server. If it isn't, it checks its local routing table ('route print' on windows) to see if there is a specific route to the mail server. If not, it will send the packet to its default gateway. (It followed this same process in order to contact the DNS server in step 3 too by the way)
5) The PC now knows where to send the packet so it creats a new connection to the mail server and sends the email to the default gateway who routes it to the mail server.
6) The mail server now has the task of delivering the message. The server might deliver mail itself but more likely, it will forward Internet-bound email to another device that will check the message against security policies for things like viruses, spam, data loss prevention, size, content, it may add a disclaimer to the message, etc.
7) After checking out ok against policies, the message needs to be delivered. The server sending the message knows that the destination is bob@contoso.com but it needs to know the IP address of the server where it needs to send the message. It performs a DNS query using root hints to get a list of .com DNS servers. Root hints servers are at the highest level of the DNS heirarchy on the Internet. Root Hints servers know which servers handle .com, .net, .org, .etc. Those servers then know who handles hotmail.com, google.com, and so on and so forth. Getting back to the task, the corporate DNS server now has a list of .com DNS servers. It then sends another query to a .com DNS server looking for contoso.com and gets a response of Contoso's public DNS server. A third DNS query is now sent to Contoso's public DNS server asking for MX (Mail Exchanger) records for the contoso.com domain. The contoso.com DNS server responds with those records and any preferences assigned. Finally, the corporate DNS server replies to the mail server with the IP addresses of contoso.com's mail servers. Phew!
8) The mail server at acme.com chooses the MX record with lowest preference and opens a connection to TCP port 25 on that server. This connection must be allowed to traverse firewalls at both acme and contoso.
9) Depending on the type of anti-spam device that is in use at contoso, several checks can now take place before the message is even sent. Contoso's Antispam device can check the reputation of the IP address that is sending the message (Acme's public IP) against databases such as senderbase, spamhaus to see if it is a known spammer. If there is a match, the antispam device will most likely end the connection. The idea behind all these checks is to verify that the sender is not a spammer and that the message did in fact come from the actual sender rather than being spoofed (forged). So, if the connection is ok so far, acme will send contoso a helo with a greeting that identifies itself as mail1.acme.com. Contoso might then perform reverse greeting and reverse DNS checks. In a reverse greeting check (hotmail does this), contoso will perform its own DNS queries to look up mail1.acme.com and will open a connection to that server. It will then compare the greeting it receives from this known correct server to the greeting it was given eariler since the sending box is claiming to be mail1.acme.com. If the greetings don't match, mail can be rejected, throttled and your senderbase score will drop. Next, a reverse DNS check is performed. The mail server at acme.com performs a DNS lookup on the IP address with which is has just formed a connection. Reverse DNS is maintained by the Internet Service Provider for a given block of IP Addresses. The reverse IP should resolve to the name of the mail server namely, mail1.acme.com. If the reverse dns does not match, mail can be rejected, throttled and your senderbase score will drop.
10) Assuming acme.com has everything setup correctly and everything checks out, the server at contoso will respond with a 220 or "go ahead". The mail server at acme now sends the recipient information. Before proceeding any further, the receiving mailserver at contoso will then lookup the recipient to verify that he/she exists. If not, the connection ends.
11) Sender information is sent which again is compared with the sending domain to make sure there's no switching going on.
12) Next, size and content is evaluated by contoso's anti-spam products, the message is scanned for viruses, etc and is finally delivered to contoso's mail server and the recipient's inbox.
And all you had to do was click "Send"! :-)
I hope this has been informative and look for a post on troubleshooting this process in the future. Thank you for viewing.
Paul Ackerman
No comments:
Post a Comment