User manual SONICWALL EMAIL SECURITY APPLIANCE ADMINISTRATOR GUIDE 7.3

[. . . ] SonicWALL® Email Security Appliance Administrator Guide Version 7. 3 SonicWALL, Inc. 2001 Logic Drive San Jose, CA 95124-3452 Phone: +1. 408. 745. 9600 Fax: +1. 408. 745. 9300 E-mail: info@sonicwall. com Part Number: 232-001974-00 Rev A SonicWALL® Email Security Appliance Administrator's Guide Version 7. 3 SonicWALL, Inc. 2001 Logic Drive San Jose, CA 95124-3452 Phone: +1. 408. 745. 9600 Fax: +1. 408. 745. 9300 E-mail: info@sonicwall. com Copyright Notice © 2010 SonicWALL, Inc. Under the copyright laws, this manual or the software described within, can not be copied, in whole or part, without the written consent of the manufacturer, except in the normal use of the software to make a backup copy. The same proprietary and copyright notices must be affixed to any permitted copies as were affixed to the original. This exception does not allow copies to be made for others, whether or not sold, but all of the material purchased (with all backup copies) can be sold, given, or loaned to another person. [. . . ] SonicWALL Email Security determines whether the IP address from which the message was sent matches the purported domain. Many organizations publish their list of IP addresses that are authorized to send email so that recipient's MTAs can authenticate the domain of messages that claim to be from that address. SonicWALL Email Security uses the following system to determine if the sender is authorized to send email from the purported address: 1. Stores the IP address of the SMTP client that delivered the message, which is the Source IP address. Finds the sender of the message, and stores the domain that the message claims to be from. Using the Domain Name System (DNS), queries the domain for its Sender ID record, if it is published. Those records are published by many domain owners, and create a list of IP addresses that are authorized to send mail for that domain. Validates that the domain authorizes the Source IP address in its SPF record. Below is a simple example: SonicWALL Email Security receives a message from 192. 0. 2. 128 In the message, SonicWALL Email Security finds From: John. Smith@example. com so it uses example. com as the domain. SonicWALL Email Security queries example. com for its SPF record The SPF record published at example. com lists 192. 0. 2. 128 as a system that is authorized to send mail for example. com, so SonicWALL Email Security gives this message an SPF = pass result. This information is taken into account by SonicWALL Email Security in the determination of spam. Sender ID or SPF Implementation Notes To use Sender ID or SPF effectively, SonicWALL Email Security must be the first-touch server. SonicWALL Email Security factors each message's SPF score as a portion of information used by its spam- detection engine. SonicWALL Email Security needs the Source IP address of the SMTP client sending messages. Thus, if your SonicWALL Email Security is downstream from another MTA, for example, Postfix or SendMail, this check will not provide useful information, since all of the messages will come from the IP Address of your Postfix or SendMail server. SonicWALL Email Security Administrator's Guide|44 Note: SonicWALL Email Security performance might vary if you enable Sender ID because each email is placed on hold while the DNS server is being queried. Effects of SPF on Email Security Behavior SonicWALL Email Security relies on SPF to help define a message as spam or likely spam. As implemented, SPF can return a soft failure or a hard failure when validating the sender's MAIL FROM field. A hard failure causes the message to be marked as likely spam even when no other test confirms it. With confirmation from another Email Security plug-in, the message can be marked as definite spam. A soft failure by SPF lends weight to the classification of a message as spam or likely spam, but is not enough to mark the message by itself. If the sending domain does not publish SPF records, Email Security does not use SPF to take any action. In cases where a certain domain is on a user's Allowed list, an SPF soft or hard failure will still prevent spam based on spoofed use of the allowed domain. Once Email Security determines that a domain has been spoofed in an incoming message, it disables checking of the Allowed list. Publishing Your SPF Record SonicWALL strongly recommends that you publish your SPF records to prevent spammers from spoofing your domain. When spammers spoof your domain, your domain can receive a high volume of bounced messages due to fraudulent or junk email that appears to come from your domain. [. . . ] The Profiler can be configured to work with each supported email client. Similar to a Honeypot, an account that is established on the Internet for the sole purpose of collecting spam and tracking hackers. A list of Internet TCP/IP addresses known to send spam, or by hosts considered friendly to spam. An SMTP proxy placed in the email flow, and performs a spam analysis to determine whether email is good or junk. [. . . ]