User manual BARRACUDA SPAM AND VIRUS FIREWALL 5.0 ADMINISTRATOR GUIDE

[. . . ] Barracuda Spam & Virus Firewall Administrator's Guide Version 5. x Barracuda Networks Inc. Campbell, CA 95008 http://www. barracuda. com Copyright Notice Copyright 2004-2010, Barracuda Networks www. barracuda. com v5. 0-101101-03-1102 All rights reserved. Use of this product and this manual is subject to license. Information in this document is subject to change without notice. Trademarks Barracuda Spam & Virus Firewall is a trademark of Barracuda Networks. [. . . ] For more details about Outbound Relay, refer to Configure Scanning of Outgoing Mail34. Configure Invalid Bounce Suppression on the BLOCK/ACCEPT > Sender Authentication page and enter a Bounce Suppression Shared Secret as a non-null password which will be included in the headers of valid emails sent from and bounced back to the Barracuda Spam & Virus Firewall. Email bounces that don't include the password will be blocked if this feature is enabled. 68 Barracuda Spam & Virus Firewall Administrator's Guide In a clustered environment, the Bounce Suppression Shared Secret will be synchronized across all Barracuda Spam & Virus Firewalls in the cluster. Sender Policy Framework (SPF) Sender Policy Framework (SPF) is an open standard specifying a method to prevent sender address forgery. The current version of SPF protects the envelope sender address, which is used for the delivery of messages. SPF works by having domains publish reverse MX records to display which machines are designated as mail sending machines for that domain. When receiving a message from a domain, the recipient can check those records to make sure mail is coming from a designated sending machine. If the message fails the SFP check, it is assumed to be spam. Enabling this feature does create more performance overhead for the system due to the multiple DNS queries needed to retrieve a domain's SPF record; for this reason, the default setting is No (off). For more information on SPF, please visit http://www. openspf. org. Messages that fail SPF check can be tagged or blocked and will be logged as such. The recommended setting is to Tag messages identified by SPF as spam so that if there is any possibility that a message is legitimate, it will be allowed to go on to the next stage of processing. Configure the Sender Policy Framework feature from the BLOCK/ACCEPT > Sender Authentication page. Exemptions from SPF Checking - Trusted Forwarders and Encryption Note that if you want to use encryption for outbound email, you must create an SPF Exemption IP entry on the BLOCK/ACCEPT > Sender Authentication page for the Barracuda Email Encryption Service: SPF Exemption IP: 64. 235. 144. 102 Netmask: 255. 255. 255. 255 You may specify a list of Trusted Forwarder IP addresses, on the BASIC > IP Configuration page, which will be ignored when performing SPF checks, as well as rate control and IP Reputation checks. Trusted Forwarders are mail servers that are set up specifically to forward email to the Barracuda Spam & Virus Firewall from outside sources. The Barracuda Spam & Virus Firewall scans the IP addresses in the Received From headers list of each email and performs an SPF check on the first IP address that is not in the list of Trusted Forwarders. Domain Keys (DKIM) Inspection DomainKeys is a method of email authentication that enables a sending domain to cryptographically sign outgoing messages, allowing the sending domain to assert responsibility for a message. When receiving a message from a domain, the Barracuda Spam & Virus Firewall can check the signature of the message to verify that the message is, indeed, from the sending domain and that the message has not been tampered with. Because most spam messages contain spoofed addresses, DomainKeys can help greatly in the reduction of spam. DomainKeys uses a public and private key-pairs system. An encrypted public key is published to the sending server's DNS records and then each outgoing message is signed by the server using the corresponding encrypted private key. For incoming messages, when the Barracuda Spam & Virus Firewall sees that a message has been signed, it will retrieve the public key from the sending server's Advanced Configuration 69 DNS records and then compare that key with the message's DomainKeys signature to determine its validity. If the incoming message cannot be verified, the Barracuda Spam & Virus Firewall knows it contains a spoofed address or has been tampered with or changed. The benefits of enabling this feature include: · · · · Email sender is validated Email body is validated Validation through DNS is difficult to foil DomainKeys works well with email forwarding because it doesn't deal with the relay server IP address You can choose to tag, block or quarantine both DKIM signed messages that fail the DKIM database check as well as unsigned messages, depending on how you configure DomainKeys Inspection on the BLOCK/ACCEPT > Sender Authentication page. You can also exempt domains from being tagged, quarantined or blocked if they fail this check. As stated elsewhere in this guide, it is safest to NOT exempt domain names from any kind of spam filtering due to the possibility of domain name spoofing by spammers. [. . . ] You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. [. . . ]