CONTROLLING INBOUND SMTP MAIL 669 Figure 16.15 Monitoring

CONTROLLING INBOUND SMTP MAIL 671 to agree on too much. A number of vendors, technologies, and IETF working groups have reviewed methods to help reduce spam and ensure that a message is coming from a known source. One of the problems is that SMTP is designed as an open system and has almost nothing in the way of security built into it. The other problem is that it seems the major mail vendors and ISPs take exception to anything that the others propose. Sender ID came from the MARID IETF working group that was part of the Sender Policy Framework and Caller ID. A number of major ISPs (Yahoo! and AOL) and open-source proponents have objected to parts of the Sender ID being patented. You might receive a message from someone@microsoft.com, but how could you verify that the message came from one of the mail servers that is allowed to send mail for Microsoft.com? Sender ID was developed to help verify that inbound messages are indeed originating on servers that should be sending messages for a particular domain. A mail server that can examine a message s headers and verify that the message is indeed coming from a valid server for the sender s domain can help reduce the number of spoofing or phishing attacks as well as determining whether a message is valid. To determine the validity of a sender s server, an algorithm called the Purported Responsible Address (PRA) is used. The PRA algorithm has to examine the entire message and the message headers (including the MAIL FROM, Resent- Sender, Resent-From, Return-Path, Received, or other message headers that may indicate the sender s SMTP address). The PRA algorithm determines the purported responsible address for the message. Once the PRA is determined, the SMTP headers must be examined to determine the server that was responsible for sending the message to your organization. To do that, Exchange must know all of the SMTP servers (Exchange and otherwise) within your organization or at a managed provider, if you are using one. Once the server that is responsible for delivering a message to your SMTP servers is determined, then DNS is queried to locate the SPF records for the sending organization s SMTP servers. The SPF record must include any relays or smart hosts that the sender might use. NOTE Microsoft has a place on its website dedicated to getting more information about Sender ID; visit www.microsoft.com/senderid for more information. Setting Up DNS SPF Records Even if you don t plan on using Sender ID as part of your antispam or sender verification strategy, you still need to set up the DNS SPF records. The DNS SPF records are used by hosts to which your servers send messages. So if someone you are sending to starts using Sender ID as one of the criteria for evaluating spam (or, heaven forbid, they reject the message entirely if it does not have a Sender ID record), then this can cause problems for the delivery of your organization s records. The DNS SPF record indicates a list of servers that are authorized to send outbound SMTP mail for your organization. You can easily check to see whether your organization or any other has SPF records created using NSLOOKUP. The following is a simple example of an SPF record for somorita.com: C:>nslookup -q=TXT somorita.com Server: kilauea1.volcanosurfboards.com Address: 192.168.254.15 somorita.com text = v=spf1 mx ip4:131.107.2.200 ip4:131.107.2.201 -all This MX record identifies that the servers with MX records for Somorita.com can send mail for somorita.com as well as the IP addresses 131.107.2.200 and 131.107.2.201. This is a fairly simple record but would be sufficient for a small organization. The nice part is that no one expects you to remember the syntax of the SPF records. Microsoft has a web-based wizard that will take you through the process of asking which servers are able to send

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost adult Web Hosting services

Bookmark the permalink.

Comments are closed.