|
|
LibAntispam Configuration(for use with MTA)
Here, we can explain how to setup LibAntispam for use in association with an MTA (Mail Transport Agent). At this moment; Sendmail-8.14.x, MeTA1-1.x, Exim-4.x and Postfix-2.8.x are the MTAs with stable LibAntispam support (provided by means of patches files). The LibAntispam support to Sendmail-X was discontinued (use MeTA1 MTA instead). We not plan to extend the LibAntispam support, in the future, to other MTAs distributions, but we appreciate if anybody do it and send us the patches! :-)
Local user account configurations are in /etc/antispam/users. However, it is recommended that you use LibAntispam-GUI to enable the change of the local users antispam preferences (but NOT NECESSARILY by users themselves). Before we continue, a warning must be given about the sintaxes of IP numbers in theses files: Should you ever edit these files on your own (i.e. using a vi or emacs editor), be aware that you HAVE TO insert the prefix IPv4: before IPv4 IP numbers and the prefix IPv6: before the IPv6 IP numbers. If you edit these files using the browser interface of LibAntispam-GUI, then you SHOULD NOT insert any prefix before the IPv4 and/or the IPv6 numbers. The use of IP netmasks in CIDR format is now fully supported. LibAntispam work with Sendmail-Classic IP/network format (i.e. 10.0.0.2 for a single IP number, 10.0.0. for a class C, 192.168. for a class B, 3ffe:2b20:101:13d: for a /64 IPv6 network, etc) and with CIDR format (i.e. 10.0.0.0/24, 192.168.0.0/26, 2001:13f0:5c3:4773::/64, etc). In the subsequent development, we will explain each of these files in details: mta-antispam.confThis is the main configuration file of LibAntispam. It controls the MTA functionalities. The mta-antispam file has 8 sections, which are show next. Section 1: General Configurations Enable/Disable MTA LibAntispam support: This option enables or disables the LibAntispam functionalities. It is recommended that you keep the default value (enable). Default policy: With this option the administrator can choose the default antispam behavior for LibAntispam in the MTA system, in case a local user does not have a personal antispam configuration (an entry in control.users file) or if a "default" entry does not exists in control.users file. The default antispam behavior is 'procced all tests' (strongly recommended). Keep the default option, and allow local users to change their personal antispam options themselves (most strongly recommended). Your valid network(s) FQDN(s) (your local domain(s)): The fulfillment of this field is mandatory! Enter your network(s) FQDN(s) (Fully Qualified Domain Name) - which are used in valid E-mail addesses - as a list of elements separated by commas. Important: any mention of your domain(s) in the MAIL FROM command for incoming mails will result in rejected relay, in case the sender is not a local client, and if the restriction "MAIL FROM cmd verifications" is enabled below! Examples: mydomain-1.foo.org, mydomain-2.foo.org NOTE: Wildcards (such as *.foo.org) are allowed only in the begin of FQDN! Your valid network(s) IP(s) (IPv4 and/or IPv6): The fulfillment of this field is mandatory! Enter your valid network(s) IP(s) number(s). This information will be used to allow your local clients: (i) to send mail to your internal/administratives mail addresses (restricted users), which you will have configured using in control.users file, (ii) to send mail with sender defined as localuser@your.domain or null reverse-path "<>", and (iii) to bypass all checks, such as reverse, dialup, GrayList, etc. It does not bypass mail to invalid users. As said above, you should write network numbers in Sendmail-Classic format (i.e. 10.0.0.) or with netmasks in CIDR format (i.e. 10.0.0.0/24). Examples: 146.146.9.3, 146.164.11., 2001:22ff:4d1:9922:, 200.222.0.64/26 NOTE: Localhosts in IPv4 and IPv6 format (i.e. 127.0.0.1 and ::1) are already set internally!!! Valid network(s) IP(s) (IPv4 and/or IPv6) from your friends: The fulfillment of this field is optional!!! This information will be used to allow that friendly networks clients: (i) send mail to your internal/administratives mail addresses (restricted users), which you will have configured using the control.users file, (ii) send mail with sender defined as localuser@your.domain or null reverse-path "<>", and (iii) to bypass all checks, such as reverse, dialup, GrayList, etc. It does not bypass mail to invalid users. This is similar to the last option! Examples: 146.164.0.0/16, 200.120.3., 2001:22fe: Default options for new users accounts created by LibAntispam-GUI: The fulfillment of this field is optional!!! Template for new user options used to define the default options to be given to a new user account when LibAntispam-GUI is used to create it! The user options is write in control.users file and the default configuration in LibAntispam-GUI is to set a new user as an invalid user. Section 2: Enable/Disable features NOTE: If you plan to allow users to modify their personal configurations, keep the default values in this section, and create a default user entry in Control-Users list (control.users file)! Enable/Disable Reverse DNS verification in agreement with RFC-1912: If this option is enabled, a remote host IP should point to a valid FQDN, and this FQDN should to point to the remote host IP. Keeping the default option enabled is recommended! Example: smtp.foo.org point to IP 10.0.0.13 IP 10.0.0.13 point to smtp.foo.org Enable/Disable Reverse FQDN substrings control list: If this option is enabled (which is useful in association with the last option also being enabled), the system administrator or local users can block remote SMTP connections from machines that have prohibited substrings in its reverse DNS FQDN. Keeping the default option enabled is recommended! Example: If you enter the string adsl in Rejected FQDN substrings rules (rejected.FQDN.strings file) and if a remote host with FQDN 4.64.178.200-adsl.foonet.com.br connects to your MTA, then the MTA will reject the SMTP connection since adsl is now a prohibited substring for any FQDN in hostname of machines connecting to your MTA. NOTE: In case remote ISP network administrators try to configure silly reverse DNS FQDN, such as 293984.foolishnet.co.br, you may enter the commercial substring name of the ISP (foolishnet) in rejected.FQDN.strings list. That solves the problem by blocking the commercial name of the silly ISP. Quite simple :-) Enable/Disable accepted hosts control list: This option enables the control of accepted hosts. Accepted hosts are in an intermediate situation, between normal hosts and friendly hosts. The accepted hosts bypass all antispam checks, but they cannot send messages to your invalid (of course) or restricted users, they cannot use your local domains in MAIL FROM smtp command, and they cannot use null reverse-path "<>" in MAIL FROM smtp command. It is strongly recommended that you keep the default option enabled! NOTE: You can put literal hostnames (FQDN) in the accepted.hosts file, but this is not recommended. You may do it at your own risc - it is strongly recommended that you use IP numbers instead! Enable/Disable good MAIL FROM addresses control list: This option enables the control of good addresses in MAIL FROM command. Good MAIL FROM addresses are in an intermediate situation, between normal users and friendly users. The good MAIL FROM addresses bypass the most of antispam checks, but they cannot: (i) send messages to your invalid (of course) or restricted users, (ii) the local domains cannot be placed in this list, (iii) the NULL reverse-path "<>" cannot be placed in this list, (iv) the MAIL FROM command restriction using SPF is not disabled *, (v) - GrayListing check is not disabled *, (vi) - RDSSC check is not disabled *. NOTE: * = If they were enabled by administrator or users! Enable/Disable users control list: This option allows you to use control.users file, in order to create personal configuration for local user account addresses or for administrative account addresses. It is very useful - once again, you are strongly recommended to keep this option enabled! Enable/Disable private users configurations: This options allows local users to set their own antispam configurations. This is useful if you plan to use LibAntispam-GUI - keep the default option enabled! Enable/Disable BlackList support: This option enables the classic DNSBL blacklist support. The configuration of the DNSBL servers is shown in Section 5. You will probably want to keep the default option enabled as well! Enable/Disable GrayList support: This option enables the advanced graylisting support. The configuration of the graylist options is shown in Section 6. You will certainly enjoy keeping the default option enabled! Enable/Disable Remote Domain SMTP Sender Checking (RDSSC) support: This option enables the Remote Domain SMTP Sender Checking support, that will check if the sender address passed in MAIL FROM command is accepted by the remote domain or its MX servers (some MTAs implement this same functionality with others names). The configuration of the RDSSC options is shown in Section 7. You will certainly enjoy keeping the default option enabled! NOTE #1: RDSSC is usefull to verify the sender validity, so you will certainly enjoy keeping the default option enabled! NOTE #2: If SPF check is enabled and remote client checking return PASS, the RDSSC support may be bypassed! Enable/Disable BAD HELO cmd verifications: This option enables several restrictions in the HELO smtp command, in a real-time remote host SMTP connection. The configuration of the HELO cmd verification is made in Section 8 or in "Bad HELO / MAIL FROM rules" below (most recommended). Due the fact that HELO smtp command verification is not in agreement with RFC-1123, the default option is disabled, but you will certainly enjoy keeping this option enabled! Enable/Disable MAIL FROM cmd verifications: This option enables several verifications in the MAIL FROM smtp command, in a real-time remote host SMTP connection. The configuration of the MAIL FROM cmd verification options is shown in Section 3. Keep the default option enabled! Enable/Disable Basic IP/Network block (refuse) list support: This option enables the basic IP/Network block list (so that LibAntispam refuses connection from single machine IP number or from a machine in a single network). The IP/Network lists can be created as explained in Section 8 (which is not recommended for large lists) or they can be created in prohibited hosts rules (prohibited.hosts file - this is recommended for a large lists). Keep this option enabled! NOTE: This list works only with IP or Network numbers, not FQDN! Section 3: MAIL FROM cmd restrictions NOTE: If you plan to allow local users to modify their personal configuration, then keep the default values in this section, and create a default user entry in Control-Users list (control.users file)! Enable/Disable null reverse-path restrictions: This option reserves the use of null-reverse path "<>" for local network clients only, and for your friendly networks clients as well. This is useful because SPAMMERS really enjoy using null-reverse path as they send thousands of SPAM messages. You are not encouraged to disable this option! Enable/Disable local domains restrictions: This option reserves the use of local domains in the MAIL FROM smtp command for valid networks(s)/IP(s), and for valid friendly network(s)/IP(s). Spammers enjoy using your local domain(s) in MAIL FROM smtp command, so keep this option enabled! Enable/Disable Sender Policy Framework (SPF) restrictions: Sender Policy Framework is described by RFC-4408 (experimental) and is used to prevent the sender ID forgery, if the domain declared during the MAIL FROM cmd has a SPF record published in its DNS database. You are not encouraged to disable this option! Enable/Disable prohibited characters verification: This option restricts the use of the "prohibited" characters in mail addresses strings transmitted in the MAIL FROM smtp command. These characters are not actually forbidden, but probably unwanted, because they are not frequently used to create E-mail addresses. SPAMMERS frequently use the "prohibited" characters in order to confuse the recipient users. Below you can see the list of prohibited characters. If you need, you can modify the list as well. I recommended keeping this option enabled! Prohibited characteres in MAIL FROM command: This is a comma-separated list. All occurrences of one or more characters from the list will result in rejected relay if the restriction is enabled. Note that the characteres ( . - @ < > , ) are not accepted as prohibited characteres. The default list of prohibited characters is: | , \ , _ , ~ , ` , ! , # , $ , % , ^ , & , * , ( , ) , { , } , [ , ] , " , ' , ; , : , ? , / NOTE #1: Any character between '+' and '@' are not treated as prohibited characters to void problems with some list servers like Majordomo2. NOTE #2: The characters ':' , '[' and ']' are prohibited characters only before the '@' character because they can be used in literal IPv4/IPv6 numbers, but only if literal IPv4/IPv6 numbers can be resolved and replaced by FQDNs. NOTE #3: The fulfillment of this field is optional!!! Prohibited characters for new users accounts created by LibAntispam-GUI: Template for new user options used to define the default prohibited characters to be given to a new user account when LibAntispam-GUI is used to create it! NOTE #1: This is entirely optional, so the administrator may keep the default value as well!!! NOTE #2: This options is used only for LibAntispam-GUI, not affect directly any LibAntispam functionality! NOTE #3: If you change this option, it is better that you save all LibAntispam configuration before create new users! Enable/Disable bad MAIL FROM verifications: This option restricts the use of the bad users and/or domains in mail addresses strings transmitted in the MAIL FROM smtp command. These bad users and/or domains probably are unwanted, because they are frequently used in SPAM E-mail addresses. SPAMMERS frequently use the bad users and/or domains in order to confuse the recipient users. Below you can see the list of bad users and/or domains (i.e. user@, user@FQDN or @FQDN). If you need, you can modify the list as well. I recommended keeping this option enabled! Unwanted characters (in begin or end of username part) in MAIL FROM sender command: This IS NOT a comma-separated list. The occurrence of one of theses characters in the begin or the end of username part of the MAIL FROM sender passed address will result in rejected relay if the command rule !cuwcbe() exists in the bad HELO / MAIL FROM rules list. This list differ from the prohibited characters list because while the prohibited characters are checked in the entire MAIL FROM string, the unwanted characters are checked only in the first character and the last character of the username part of the sender address passed in MAIL FROM cmd. Spammers engines like to use fake-addresses that use unwanted characters at the begin or the end or the username part of the MAIL FROM sender address, i.e. <_kdjfhh@somewhere.foo>, <-mail@someisp.faa>, etc. So, if you want to accept addresses that contain the undescore character "_", i.e. <name_surname@somewhere.foo>, but want rejected addresses that use the undescore at the begin or end of username part, i.e. <_dkjfjh@someisp.foo>, just remove the undescore character from the prohibited characters and leave it in this unwanted characters list. NOTE #1: This list IS NOT a comma-separated list! NOTE #2: This list is USED ONLY if the !cuwcbe() command rule exists in the bad HELO / MAIL FROM rules list. NOTE #3: The size of this list is restricted to the 255 characters. NOTE #4: The characters @, < and > in this list are ignored, EVER! NOTE #5: Alphanumeric characters in this list are ignored too! Section 4: Sender Policy Framework (SPF) options Default behavior for GrayListing if SPF return the PASS condition: This option set the default behavior for GrayListing if SPF return the PASS condition, there are two valid behaviors: Bypass or Not-Bypass. The descriptions for these behaviors is showed below: Bypass = GrayListing is bypassed if SPF return PASS; Not-Bypass = GrayListing is not bypassed although SPF return PASS. (Not recommended) NOTE: The are no reason to use SPF if GrayList is not bypassed if a PASS condition occur. Default behavior for Remote Domain SMTP Sender Checking (RDSSC) if SPF return the PASS condition: This option set the default behavior for RDSSC if SPF return the PASS condition, there are two valid behaviors: Bypass or Not-Bypass. The descriptions for these behaviors is showed below: Bypass = RDSSC is bypassed if SPF return PASS; (Recommended default) Not-Bypass = RDSSC is not bypassed although SPF return PASS. (Can be considered) NOTE: Although make no sense the use of SPF if RDSSC is not bypassed if a PASS condition occur, some administrators can use both SPF and RDSSC in a complemental way, that is SPF doing a host level authentication and RDSSC doing a user level authentication. By default, however, LibAntispam do the same default given for the GrayListing behavior option above. Default behavior for SOFTFAIL condition: This option set the default behavior for a SOFTFAIL condition, there are three valid behaviors: accept, mark and reject. The descriptions for these behaviors is showed below: Accept = Accept the SMTP connection, but with GrayListing and RDSSC verifications; Mark = Accept the SMTP connection, but with GrayListing and RDSSC verifications and mark the "Subject:" field with [SPAM] warning; (Not implemented yet) Reject = Reject the SMTP connection unconditionaly. (Not recommended) Default behavior for TEMPERROR condition: This option set the default behavior for a TEMPERROR condition (this condition may occur due non-critical or less critical conditions), there are two valid behaviors: accept and reject. The descriptions for these behaviors is showed below: Accept = Accept the SMTP connection, but with GrayListing and RDSSC verifications; Reject = Reject the SMTP connection unconditionaly. (Not recommended) Maximum number of recursive calls in "include" and "redirect" mechanisms: This option set the maximum number of recursive calls in SPF "include" and "redirect" mechanisms and is intended to prevent DDoS attacks. NOTE: Valid values between 5 and 20 recursive calls. System default is set to 10 recursive calls. Section 5: BlackList options NOTE: Users can enable or disable the use of the DNSBLs that you define at this point, if you allow so, but they cannot modify any of the lists! IPv4 blacklists: You can edit (or add new entries to) your favorite DNSBL lists of IPv4 addresses. Default lists are rsbl.aupads.org and orvedb.aupads.org. IPv6 blacklists: You can edit (or add new entries) your favorite DNSBL lists of IPv6 addresses. No default list exists at the moment. In the future, the default lists will be ip6.rsbl.aupads.org and ip6.orvedb.aupads.org. Section 6: GrayList timeout options NOTE #1: If you plan to allow local users to modify their personal configurations, then keep the default values in this section, and create a default user entry in Control-Users list (control.users file)! NOTE #2: Local users can only override the GrayList Delay Time Option! GrayList Delay Time: This is the time, in minutes, that the MTA will wait after the first attempted SMTP connection (from a remote host, with a message from anyusers@anywhere to anylocaluser@yourlocaldomain), before it accepts another SMTP connection (from the same remote host, with a message from the same anyuser@anywhere to the same anylocaluser@yourlocaldomain). In others words, this is the minimal life time of a graylist entry in a graylist-host database. Values can change from 1 minute to 30 minutes. The default value - 5 minutes - is a good choice; using values below 5 minutes is not recommended! GrayList Timeout Time: The maximal time, in hours, during which a graylist entry exists in a graylist-host database. Values can change from 1 hour to 24 hours. The default value is - 12 hours - and is a good choice; using values below 6 hours is not recommended! GrayList Lifetime Time: The maximal time, in days, during which a graylist-host database exists without any change (changes imply adding new ones, or removing any graylist entry). Values can change from 1 day to 60 days. The default value - 30 days - is a good choice; using values below 7 days is not recommended! NOTE: In practice this option is used only if the MTA server becomes inoperative for a very long time and comes back much much later - because, in regular MTA operation, if a graylist-host database reaches 0 bytes (while graylist entries keep being removed), then LibAntispam removes it from graylist stack. GrayList temporary relay deny message: With this option, the administrator can configure an optional message for a temporary relay deny notification while graylist action is running. This message overrides the standard temporary relay deny message that the MTA keeps sending to a remote non-local client until the GrayList Delay Time is over. This is entirely optional, so the administrator may keep the default value as well. NOTE: Do not insert unusual characters such as ", \, $, ~, |, ', %, etc., in the temporary relay deny message. The temporary relay deny message size should be between 1 and 255 characters. Section 7: Remote Domain SMTP Sender Checking (RDSSC) options NOTE #1: All values, except Pseudo-User that perform the SMTP sender checking, in this section are optionals, don't change anything here if you don't know what you are doing!!! Leave the default values!!! NOTE #2: Local users cannot override these options! seudo-User that perform the SMTP sender checking (will be used in the MAIL FROM command of RDSSC): This option set the pseudo-user that will be used in the MAIL FROM command during the SMTP sender checking. NOTE #1: It's recommended to use a pseudo-user different from postmaster or mailer-daemon because these pseudo-users are already used to MTA administrators receive important MTA warnings and messages from local users or from others remote users or administrators and, probably, you want to restrict the postmaster or mailer-daemon pseudo-users to void that SPAMMERs send messages to them. If you use these pseudo-users (postmaster or mailer-daemon) instead of the default postchecker pseudo-user, for safety, LibAntispam will internally disable any antispam rules for them (as is usually common in several MTAs RDSSC-like implementations), so these pseudo-users will become more vulnerable to receive SPAM messages. If you use the postchecker pseudo-user, LibAntispam will deny any DATA SMTP command if any address after the MAIL FROM or RCPT TO commands has the format NOTE #2: If you use the default "postchecker" pseudo-user, you don't need to add any "postchecker" entry in the /etc/aliases files of your MTA servers (i.e. postchecker: /dev/null). The "postchecker" pseudo-user is an internal user only used by LibAntispam's MTAs. NOTE #3: The FQDN used as domain part for the address of this pseudo-user will be discovered using the standards C functions gethostname() and gethostbyname(). Be sure that your file /etc/hosts is correctly filled to void problems. Alternatively, you can set the FQDN in the RDSSC_FQDN below, but it is recommended that you do it only if the gethostname() and gethostbyname() don't return you machine FQDN correctly or if you want to use a specific FQDN for the pseudo-user address. The FQDN for pseudo-user that perform the SMTP sender checking (will be used in the MAIL FROM command of RDSSC): You can set the FQDN of address domain part for the pseudo-user that you set above. THIS OPTION IS OPTIONAL! Any FQDN string here has at least one dot point and 4 characters. NOTE #1: This is entirely optional, so the administrator may keep the default value (empty) as well!!! NOTE #2: Leave empty to the standard C functions gethostname() and gethostbyname() discover the real FQDN for the current MTA machine. NOTE #3: To void problems, the passed FQDN should match or be a sub-domain (if you used wildcards in the begin of the FQDN) of one of domains passed in Your valid network(s) FQDN(s) option above. NOTE #4: Do not insert unusual characters such as ", \, $, ~, |, ', %, etc in the FQDN. If you put, the FQDN will be ignored by LibAntispam!!! NOTE #5: The FQDN that you put here will not be verified if it resolve or has any valid MX server! BE CAREFULL!!!! NOTE #6: Maximal FQDN size is 255 characters, minimal is 5 characters (including 1 dot point character). NOTE #7: If you don't know what you are doing, LEAVE THIS OPTION BLANK!!!! NOTE #8: Read the comments for Pseudo-User that perform the SMTP sender checking above! RDSSC SMTP connection attempt timeout: The connection timeout is the time that the LibAntispam checking function will wait for an successfully connection to a remote SMTP server. If the timeout is reached, will return fail and will attempt to use other MX server or will return fail. NOTE #1: The default 20 seconds value is enough for broadband networks. NOTE #2: Values below 10 seconds or above 40 seconds are not recommended. NOTE #3: If you don't know what you are doing, LEAVE THE DEFAULT OPTION!!!! RDSSC SMTP command timeout: The command timeout is the time that the LibAntispam checking function will wait for a SMTP command's reponse from a remote SMTP server. If the timeout is reached, will return fail and will attempt to use other MX server or will return fail. NOTE #1: The default 15 seconds value is enough for broadband networks. NOTE #2: Values below 10 seconds or greater than 30 seconds are not recommended. NOTE #3: If you don't know what you are doing, LEAVE THE DEFAULT OPTION!!!! Default behavior for RDSSC TRANSIENT FAILLURE conditions: This option set the default behavior for a RDSSC TRANSIENT FAILLURE condition (this condition may occur due non-critical or less critical conditions in SMTP check session), there are two valid behaviors: delay and reject. The descriptions for these behaviors is showed below: Delay = Increment the delay time in GrayListing verifications; Reject = Reject the SMTP connection unconditionaly. (Not recommended) NOTE: Due RDSSC checks may generate several false positive occurrences, it is recommended to leave the default delay option enabled! The delay time in GrayList will be incremented by a factor between 3 and 4. Default behavior for RDSSC PERMANENT FAILLURE conditions: This option set the default behavior for a RDSSC PERMANENT FAILLURE condition in SMTP check session, EXCEPT if the RDSSC's RCPT TO command return this condition. This condition may occur due critical or unknown conditions (due bad antispam implementation on remote SMTP servers), there are two valid behaviors: delay and reject. The descriptions for these behaviors is showed below: Delay = Increment the delay time in GrayListing verifications; Reject = Reject the SMTP connection unconditionaly. (Not recommended) NOTE: Due RDSSC checks may generate several false positive occurrences, it is recommended to leave the default delay option enabled! The delay time in GrayList will be incremented by a factor between 4 and 5. Section 8: Usefull LibAntispam lists NOTE: The following usefull LibAntispam lists are not a replacement for the standard LibAntispam lists, such as Accept Hosts rules for example, but they help administrators that prefer to work with fewer configuration files. However, if you plan to handle a large number of IP numbers, networks or FQDNs, we strongly recommended that you keep these lists empty, and user the Accept Hosts rules, Prohibited Hosts rules, Bad MAIL FROM addresses / BAD HELO domains/IPs/Networks and Good MAIL FROM addresses instead. Basic IP/Network accept (not friends hosts/networks) list Accepted IP(s)/Network(s) (IPv4 and/or IPv6, FQDN is not recommended): A comma-separated list containing remote hosts (IPs or Networks) from whom the local MTA will accept (possibly with some restrictions) any SMTP connection. Pay attention to the difference between Accepted hosts with Friendly hosts! This is an optional item. NOTE: If you plan to have many IP/Networks in the accepted lists, then use the accepted host rules instead of the item above! Basic IP/Network block (refuse) list Prohibited IP(s)/Network(s) (IPv4 and/or IPv6): A comma-separated list containing remote hosts (IPs or Networks) from whom the local MTA will deny any SMTP connection. This item is optional. NOTE: If you plan to have many IP/Networks in prohibited lists, then use the prohibited host rules rather than the item above! Basic bad HELO block (refuse) list: Non-wanted Domain(s)/IP(s)/Network(s) (FQDN, IPv4 and/or IPv6) in HELO smtp cmd. A comma-separated list containing FQDN(s), IP(s) or Network(s) that the local MTA will reject in HELO SMTP command. NOTE: If you plan to have many FQDN(s)/IP(s)/Network(s) in bad HELO domains lists, then use the bad HELO / MAIL FROM rules instead of the item below! Basic bad MAIL FROM block (refuse) list: Non-wanted user(s), domain(s) or address(es) (FQDN) in MAIL FROM smtp cmd. A comma-separated list containing addresses in FQDN format, i.e., user@, user@FQDN, @FQDN or FQDN, that the local MTA will reject in MAIL FROM SMTP command. NOTE: If you plan to have many addresses in bad MAIL FROM addresses lists, then use the bad HELO / MAIL FROM rules instead of the item below! Basic good MAIL FROM allowed list: Wanted user(s) address(es) in MAIL FROM smtp cmd. A comma-separated list containing addresses in FQDN format, i.e., user@, user@FQDN, @FQDN, *@FQDN, FQDN or *FQDN, that the local MTA will accept in MAIL FROM SMTP command. NOTE: If you plan to have many addresses in good MAIL FROM addresses list, then use the good MAIL FROM addresses rules instead of the item below! control.usersWith information from the control users configuration file, the administrator controls the LibAntispam funcionalities for each local user. A control.users entry is a single line per user. Any entry has the format: user:1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16:17:18:19:20 The fields from 1 to 20 are defined as follows: 1 - invalid_user: This user is not valid, and he/she don't receive messages. 2 - restrict_user: This user is internal, and only local/friendly hosts can send messages for him/her. 3 - restrict_post_user: This user is not allowed to send any message. 4 - warning_instead_reject: This user wants a SPAM warning added in Subject field, rather than having messages to him/her rejected. (not implemented yet!) 5 - send_notify: Send a notify message to the recipient user whenever MAIL is rejected. 6 - check_reverse: Check for existent reverse DNS and for its consistency. 7 - check_FQDN_strings: Check for prohibited substrings in reverse DNS FQDN. 8 - check_blacklist: Use the BlackList for all smtp connections. 9 - check_graylist: Use the GrayList for all smtp connections. 10 - reserved: Not used at this moment! 11 - check_mail_from_spf: Use Sender Policy Framework - SPF (need check_mail_from enabled). 12 - check_bad_helo: Restrict bad HELO cmd use. 13 - check_rdssc: Check if remote domain/mx accept SMTP connections for passed senders. 14 - check_mail_from: Check consistency of MAIL FROM cmd. 15 - check_mail_from_restrict_null_reverse_path: Restrict the use of NULL reverse-path. 16 - check_mail_from_restrict_local_domain: Restrict local domain use. 17 - check_mail_from_prohibited_chars: Restrict prohibited characters use. 18 - check_bad_mail_from: Restrict use of bad MAIL FROM cmd. 19 - check_prohibited_IP_Networks: Check the prohibited IP/Networks lists. 20 - check_message_header_analyze: Analize message header. (not implemented yet!) NOTE: For each of the field above, the acceptable values are yes or no. Some examples for control.users entries: Disable all checks for a user (three equivalent methods): somebody somebody:::::::::::::::::::: somebody:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no The same as above, for common users login accounts: john:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no ricardo:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no robin:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no:no Perform all verifications (without notifying the user): somebody:no:no:no:no:no:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes silva:no:no:no:no:no:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes josef:no:no:no:no:no:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes Perform all verifications (and notify the user): somebody:no:no:no:no:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes charles:no:no:no:no:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes debby:no:no:no:no:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes Same as above, using the complete login@hostname form at: somebody@somewhere.foo:no:no:no:no:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes charles@somewhere.foo:no:no:no:no:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes debby@somewhere.foo:no:no:no:no:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes:yes Do not check whether the reverse DNS is valid, but do check for prohibited substrings, Blacklists and prohibited IP/Networks. Do not check GrayList and MAIL FROM cmd either (if field 14 - check MAIL FROM - is disabled, then fields 11, 15, 16, 17 and 18 make no sense): somebody:no:no:no:no:no:no:yes:yes:no:no:no:no:no:no:yes:yes:yes:yes:yes:no or somebody:no:no:no:no:no:no:yes:yes:no:no:no:no:no:no:no:no:no:no:yes:no Check whether the reverse DNS is valid, but do not check for prohibited substrings. Do not check Backlists either. Do check GrayList and prohibited IP/Networks. Do not check the MAIL FROM cmd (if field 14 - check MAIL FROM - is disabled, then fields 11, 15, 16, 17 and 18 make no sense): somebody:no:no:no:no:no:yes:no:no:yes:no:no:no:no:no:no:no:no:no:yes:no Invalid and Restricted user. Warning: invalid_user fields precede all the others fields!!!! So, if a user is invalid or restricted, no other field is used: This user is restricted: somebody::yes:::::::::::::::::: This user is invalid: invaliduser:yes::::::::::::::::::: Default procedure for all users of a host "somewhere.foo" that was not found in this file! (you may create your own default procedure, for each particular host): default@somewhere.foo:no:no:no:no:no:yes:yes:no:yes:no:no:no:no:yes:yes:yes:yes:no:yes:no The global default procedure for all users who were not found in this file, and who do not have a defalt procedure specified for their particular host (see mta-antispam.conf), can be modified using the default entry below (you may create your own default procedure). The entry below represents the default procedure that is assumed, either if the control.users file does not exist, or if the user is not found and the default entry does not exist. NOTE: This entry does not accept the full login@hostname format, obviously. default:no:no:no:no:no:yes:yes:yes:yes:no:no:no:no:yes:yes:yes:yes:no:yes:no Shell-scripts that are useful to create LibAntispam-GUI user accountsThe shell-scripts are described below: CreateUserLA.sh: A shell-script for creating a single LibAntispam-GUI user account. DeleteUserLA.sh: A shell-script for deleting a single LibAntispam-GUI user account. convert_passwd.sh: This shell-script converts from standard users and encrypted passwords from Unix (Linux/FreeBSD) format to Apache authentication file format. It will append the file /usr/local/www/LA_users_pwd/passwd (if default values are used in Makefile.include). This script will append the passwd file only, so that the Admin-MTA password is not erased. NOTE: Probably, some unwanted system accounts (suchl as root, daemon, sys, mail, majordomo, etc.) will be converted as well. You may edit the passwd file that is generated, and remove these unwanted accounts before running the create_users_accounts_from_passwd.sh script. Do not delete Admin-MTA password entry! create_users_accounts_from_passwd.sh: This is a front-end of CreateUserLA.sh. It reads the file /usr/local/www/LA_users_pwd/passwd (if the default values are used in Makefile.include), and it creates the local user antispam account profiles and entries in control.users file. Example: At the prompt, if you are using the default options in Makefile.include, after installing LibAntispam and LibAntispam-GUI you can export your local user accounts to LibAntispam user accounts using the following commands (in Linux system):
The control.users list and LibAntispam-GUI (Administrative maintenance commands)The Admin-MTA account has several privileges at the use of the administrative maintenance commands: It can create or delete new users, change users access password, change the Admin-MTA password, and see, in a browser window box, the configurations of all user accounts. NOTE: Whenever you press the CHANGE button in the Admin-MTA browser window box or in an opened user browser window box (from main Admin-MTA browser window), the main Admin-MTA browser window will be automatically reloaded. rejected.FQDN.stringsThis is the rejected FQDN substrings configuration file of LibAntispam. It keeps a list of the prohibited Fully-Qualified Domain Name substrings in reverse DNS (imply Reverse FQDN substrings control list enabled). This is useful to block dial-up machines (i.e. xxx.dialup.something.foo), hosts with "generic" FQDN in reverse DNS (i.e. xxxx-avaiable.something.foo), spammers machines with fixed addresses, badly administrated ISP networks, etc. An example of a smart application of this list: If the administrators of a remote ISP network try to set up an unusual (or silly) reverse DNS FQDN, such as 293984.foolishnet.co.br (in order to prevent a correct reverse DNS verification from the MTA), you can enter the commercial substring name of the ISP (foolishnet) in rejected.FQDN.strings list. In this way, you solve the problem by blocking the commercial name of the ISP. Quite simple :-) There are some suggestive reverse FQDN names in the rejected.FQDN.strings.example files, like: avaiable, ppp, client, user, users, staticIP, etc. You can (and probably, you will want to) add many other substrings. NOTE: Be careful not to enter strings that are very short or dubious, like "rt", "zz", "ru", ".br", ".uk", etc. - those strings would get you bad results. Enter only non-dubious substrings like "ppp", ".ptr.", "slip", ".rev.", "dhcp", etc. The Rejected.FQDN.strings accept too special command rules macros to catch strings in dynamic or unused/non-registered static addresses, as follow: Anything that has three digit sets or more separated by dashs will be rejected. !cns(-,3) Anything that has three digit sets or more separated by dots will be rejected. !cns(.,3) Mean that a group of five or more digits will be rejected. !cng(5) Mean that FQDNs that use all digits of the pointed IPv4 numbers, in decimal or hexadecimal format, will be rejected. !cip4fqdn() Mean that FQDNs that use all digits of the pointed IPv6 numbers will be rejected. !cip6fqdn() accepted.hostsThis is the accepted hosts/networks configuration file of LibAntispam (this file is not for friendly hosts/networks). It keeps a list of the hosts/networks that are allowed to send mail message to your system, with some restrictions though:
Some examples... IP numbers: IPv4:10.0.0.3 IPv4:192.168.10.233 IPv6:3ffe:2b02:100:14d:103::1 Network numbers: IPv4:192.168.12. IPv4:172.16.0.0/16 IPv6:3ffe:2b02:100:1fd: IPv6:3ffe:2c02:110:21fd::/64 NOTE: If you are editing this file by your hands using an editor like vi, you should put the prefix "IPv4:" before the IPv4 IP numbers and the prefix "IPv6:" before the IPv6 numbers. If you are editing this file using LibAntispam-GUI, you should forget the "IPv4:" and "IPv6:" prefixes. prohibited.hostsThis is the prohibited hosts/networks configuration file of LibAntispam. It keeps a list of the hosts/networks that are not allowed to send mail messages to your system. Such messages will be rejected unconditionally, without any futher check (this is a basic rejection list, based on IP or network number). Some examples... IP numbers: IPv4:10.11.0.3 IPv4:192.168.20.233 IPv6:3ffe:2b02:100:14d:122::10 Network numbers: IPv4:192.168.40. IPv4:192.168.40.128/25 IPv4:172.31. IPv6:3ffe:2bee:102:2fd: IPv6:3ffe:2bee:102:2fd::/64 NOTE: If you are editing this file by your hands using an editor like vi, you should put the prefix "IPv4:" before the IPv4 IP numbers and the prefix "IPv6:" before the IPv6 numbers. If you are editing this file using LibAntispam-GUI, you should forget the "IPv4:" and "IPv6:" prefixes. mail-addresses.goodThis file has good mail addresses, passed in MAIL FROM smtp command, that SHOULD be accepted and bypass some checks as below showed: Mail addresses in this file bypass all checks, except:
* - If they were enabled by administrator or users NOTE #1: Wildcards can be used in the username part of the address, i.e. *@foo.foo, but can be omitted too, i.e. @foo.foo, and can be used only in domain name part, i.e. *foo.foo, but cannot be used after the @ character in domain name part. NOTE #2: Use WILDCARDS with CAREFULLY!!! mail-addresses_or_domains.badThis file has bad mail addresses, domains (hostnames) in FQDN format or IP/Networks in literal format that SHOULD be reject if passed in HELO (domains or IP/Network in literal format) or MAIL FROM (mail addresses and/or domains (IP numbers are converted to FQDN)) smtp commands. ATTENTION! Rejections basead in HELO argument is not in agreement with RFC-1123! Internally, in HELO cmd verification, the LibAntispam will check ever the argument passed to HELO as described below:
1. If IPv4 or IPv6 numbers...
(i) IP numbers SHOULD BE in literal format, i.e [ip_number]. See RFC-2821!
(ii) Verify if IP number has a valid format (dot decimal for IPv4 or
nibble format for IPv6).
(iii) IPv4 numbers SHOULD NOT be RFC-1918.
(iv) In IPv4 connections, literal IPv6 numbers are not allowed, and in
IPv6 connections, literal IPv4 numbers are not allowes too.
(v) Remote clients (non-local or non-friends) cannot use our local
IP/Networks defined in mta-antispam.conf file.
2. If domains (hostnames) in FQDN format...
(i) Cannot has any prohibited characters (if this protection is enabled!)
The characters "@", "<", ">", "," are considered prohibited in HELO
command, ever! (if this protection is enabled, obvious!)
(ii) Should has at least one dot in FQDN.
(iii) The FQDN cannot start or end with dot.
(iv) Remote clients (non-local or non-friends) cannot use our local
domains defined in mta-antispam.conf file. (if this protection
is enabled!)
(v) FQDN should resolve to an IP number (IPv6 if client start an IPv6
connection or IPv4 if client start an IPv4 connection) or...
(vi) if not, should has at least one (the best) MX record in DNS (that
SHOULD resolve!!!).
(vii) The MX record FQDN cannot match with our local domains defined in
mta-antispam.conf file.
(viii) IPv4 numbers, resolved in (v) can be a RFC-1918, but its MX records
SHOULD BE valid IPv4 numbers, IPv4 numbers resolved in (vi) SHOULD
NOT be RFC-1918 and IPv6 numbers in (v) and (vi) SHOULD has a valid
format.
(ix) Resolved IP number for hostnames or MX records cannot match with our
local IP/Networks defined in mta-antispam.conf file.
Internally, in MAIL FROM cmd verification, if RESTRICT_LOCAL_DOMAINS_USE is enabled, the LibAntispam will check ever the argument passed to MAIL FROM as described below:
1. If IPv4 or IPv6 numbers (if administrator don't prohibit literal IP
numbers in MAIL FROM or RCPT TO commands)...
(i) IP numbers SHOULD BE in literal format, i.e [ip_number]. See RFC-2821!
(ii) Verify if IP number has a valid format (dot decimal for IPv4 or
nibble format for IPv6).
(iii) IPv4 numbers SHOULD NOT be RFC-1918.
(iv) In IPv4 connections, literal IPv6 numbers are not allowed, and in
IPv6 connections, literal IPv4 numbers are not allowes too.
(v) IPv4 or IPv6 numbers SHOULD resolve to a FQDN, that will replace the
IP number, and the checks for domains (hostnames) below are proceeded.
2. If domains (hostnames) in FQDN format...
(i) Cannot has any prohibited characters (if this protection is enabled!)
(ii) Should has at least one dot in FQDN.
(iii) The FQDN cannot start or end with dot.
(iv) Remote clients (non-local or non-friends) cannot use our local
domains defined in mta-antispam.conf file (if this protection
is enabled!).
(v) FQDN should resolve to an IP number (IPv6 if client start an IPv6
connection or IPv4 if client start an IPv4 connection) or...
(vi) if not, should has at least one (the best) MX record in DNS (that
SHOULD resolve!!!).
(vii) The MX record FQDN cannot match with our local domains defined in
mta-antispam.conf file.
(viii) IPv4 numbers, resolved in (v) can be a RFC-1918, but its MX records
SHOULD BE valid IPv4 numbers, IPv4 numbers resolved in (vi) SHOULD
NOT be RFC-1918 and IPv6 numbers in (v) and (vi) SHOULD has a valid
format.
(ix) Resolved IP number for hostnames or MX records cannot match with our
local IP/Networks defined in mta-antispam.conf file.
Some examples:Pure FQDN will be rejected in both HELO or MAIL FROM command: crazy.mail.foo.br spam.idiot.foo.xx ocarteiro.idiota.co.br ocorreio.idiota.co.br Wildcards are allowed only in begin of FQDN (but make sense only for MAIL FROM verification): *.mail.foo.br *spam.idiot.foo.xx *idiota.co.br Use WILDCARDS with CAREFULLY!!! Addresses or fragments will be rejected only by MAIL FROM command (but do not use wildcards here!): All in domain spam.idiot.foo.xx @spam.idiot.foo.xx A specific user in domains crazy.mail.foo.br and ocorreio.idiota.co.br spamer@crazy.mail.foo.br ocarteiro.imbecil@ocorreio.idiota.co.br A specific user in any domain ocarteiro@ Special command rules to catch unwanted characters at the begin or the end of the mail addresses, i.e. <_kdjfhh@somewhere.foo> or <-mail@someisp.faa> or <somebody=@someplace.fee>. This is too used by SPAMMERS! NOTE: The unwanted characters list in the command rule below is internal/compiled-in and has, at the moment, the following characters: -_*&^%$#!+=|\/?.,:;'"[]{}() To use this command rule, added the macro below! !cuwcbe() LibAntispam Advanced ConfigurationsSoon... I hope! ;-) |
|
Copyright © 2002-2011 Rafael Jorge Csura Szendrodi |