Postfix Anti-Spam technology-Linux Enterprise Application-Linux server application information. The following is a detailed description. The Anti-Spam function of MTA is to filter sessions during MTA processing. This filter not only filters the Spam Sent to itself, but also prevents itself from being maliciously used to send spam. Postfix implements all major MTA filtering technologies ..
MTA filtering is divided into two types: Pre-sending filtering of mail data and post-sending filtering of mail data.
I. Pre-Data Filtering
Pre-DATA filtering refers to filtering before DATA commands are sent in SMTP sessions. In this phase, there are four subphases of Filtering: SMTP connection filtering, HELO/EHLO command filtering, mail from command filtering, and rcpt to command filtering. According to the information received in these four sub-stages, they are also called SMTP client restrictions, HELO/EHLO host name restrictions, sender address restrictions, and recipient address restrictions.
Filtering takes effect after the rcpt to command by default, because some mail clients on Windows do not process the filtering action before the rcpt to command. You can set smtpd_delay_reject to no to make the filtering action take effect immediately. This parameter also affects the filter rule parameters that can be used on different commands.
1. filter rules
The filtering rules are specified by four configuration statements in these four substages. They all receive a list of rule parameters, which can be separated by spaces or commas. By default, the values of smtpd_delay_reject are yes, which can accept all supported rules, but must take effect only after the rcpt to Command; If smtpd_delay_reject is set TO no, they can only accept five common rule parameters, filter rule parameters in the previous sub-phase, and rule parameters in this sub-phase.
They accept the following common rule parameters:
Permit
This connection is allowed. This rule is usually placed at the end of the rule list to make the rule clearer.
Defer
Inform the client that the session cannot be resumed now, and then send an SMTP connection request later. This is often used when the server needs to perform some DNS checks, but (due to DNS query timeout) does not get results in time, the client is notified to connect later. This rule is usually placed at the end of the rule list to make the rule clearer.
Reject
Reject the connection request. In this phase, the connection is disconnected, effectively saving the waste of bandwidth and processing capability caused by spam. This rule is usually placed at the end of the rule list to make the rule clearer.
By default, the deny action will not immediately disconnect after matching the deny rule, but will be disconnected after the rcpt to command is processed, this is because some defective email programs on windows do not process the reject status code sent back before the rcpt to command. You can set smtpd_delay_reject to no to immediately send a denial of status code to disconnect the connection.
Reject_code specifies the rejected return status code (554 by default ).
Warn_if_reject
After changing the rule, the denial action is a warning, that is, if there is a condition that the rejection is met, rather than the actual rejection, a warning message (reject_warning) is issued) to the log file (usually/var/log/maillog ). It is often used to test the Mail Filter rules on the actual running mail server.
Reject_unauth_pipelining
Reject the client connection that sends the SMTP command line before the Postfix supports the command line. The command line is a technology used by some mail clients to send emails quickly.
The filter rules are described in the following four sub-phases:
A. Filter SMTP connections (SMTP client restrictions)
Postfix can be used for filtering and checking when receiving client SMTP connection requests.
You can use the smtpd_client_restrictions command of Postfix to specify the filtering rules for this stage. In this phase, the available filtering rules include:
Reject_unknown_client
Deny that the customer's address does not have A corresponding dns a record or PTR record connection. Generally, some machines, especially personal dial-up users, do not have A or PTR record. Therefore, pay attention to the usage of roaming users (roaming users do not include $ mynetworks, for example, users who access the Internet by dialing at another ISP. SMTP authentication is usually used to solve this problem ).
Unknown_client_reject_code specifies the rejected return Status Code (the default value is 450 ).
Permit_mynetworks
Allow connections from clients whose IP addresses belong to the network defined by $ mynetworks. Generally, when an ISP provides SMTP services for its own dial-up users, it specifies its network through the $ mynetworks parameter and allows its machines in the network to send emails.
Reject_rbl_client domain. tld and reject_rhsbl_client domain. tld
Deny connection from addresses in the RBL and RHSBL lists. By checking whether an IP address or domain name exists in the RBL or RHSBL of domain. tld, you can determine whether the client is blacklisted in the real-time domain. tld blacklist and decide whether to accept the connection. For details about the real-time blacklist, refer to [anti-spam technical reference> real-time blacklist technology] on this site ].
Maps_rbl_reject_code specifies the rejected return status code (554 by default ).
Check_client_access maptype: mapname
Search for a maptype database named mapname. It can be matched based on the client host name, parent domain, IP address, or some IP addresses. For more information about database access, see the appendix below.
Among them, relays.ordb.org and dsn.rfs-ignorant.org are relatively Authoritative foreign free RBL and RHSBL servers.
B. HELO/EHLO command filtering (HELO/EHLO host name restriction)
After receiving the SMTP connection, you can filter and check the information sent by the HELO or EHLO commands.
Some mail clients do not send the HELO/EHLO command during communication. You can use smtpd_helo_required to set yes to force the HELO/EHLO command to be sent (by default, the Postfix does not require HELO/ehlo to be sent ).
You can use the smtpd_helo_restrictions command of Postfix to specify the filtering rules for this stage. In this phase, the available filtering rules include the public rules and the smtpd_client_restrictions rules:
Reject_invalid_hostname
Disconnections to host names in invalid format.
Invalid_hostname_reject_code specifies the rejected return status code (501 by default ).
Reject_unknown_hostname
Disconnections from unknown host names. The unknown host name means that the host does not have a dns record or MX record. Because many dialing users' machines do not have A record or MX record, pay attention to the usage of roaming users.
Unknown_hostname_reject_code specifies the rejected return status code (default value: 450 ).
Reject_non_fqdn_hostname
Disconnections to host names that are not in the FQDN format (fully qualified domain name format, that is, the full names of hosts including domain names and host names separated by points) are rejected.
Non_fqdn_reject_code specifies the rejected return status code (504 by default ).
Permit_naked_ip_address
Allow direct connection using IP addresses. Generally, the host name rather than the IP address is used in HELO/EHLO.
Check_client_access maptype: mapname
Search for a maptype database named mapname. It can be matched based on the host name and parent domain sent by HELO/EHLO. For more information about database access, see the appendix below.
C. mail from command filtering (sender address restriction)
After receiving the SMTP connection and the client sends the HELO/EHLO command (optional), the sender's identity should be declared using the mail from command. You can filter the sender's identity.
According TO the RFC specification, the mail from instruction and the following rcpt to instruction should use an email address in RFC 821 format (for example: ), But because many mail clients are not standardized, the standard RFC 821 format is often not used. By default, Postfix accepts any understandable email addresses, such as missing a pair of angle brackets in the address and comments that can contain RFC 822 format. If you want to enable the RFC 821 format restriction, you can set strict_rfc821_envelopes to yes.
You can use the smtpd_sender_restrictions command of Postfix to specify the filtering rules for this stage. In this phase, the available filtering rules include public rules and smtpd_client_restrictions rules and smtpd_helo_restrictions rules:
Reject_unknown_sender_domain
Deny the connection to the domain of the sender's email without the dns a record or MX record.
Unknown_address_reject_code specifies the rejected return Status Code (the default value is 450 ). When a temporary error occurs during DNS query (such as query timeout), 450 is always returned.
Reject_rhsbl_sender domain. tld
Deny the connection of the sender's email domain to the RHSBL blacklist. By checking whether a domain name exists in the RHSBL of domain. tld, you can determine whether the client is included in the real-time domain. tld blacklist and decide whether to accept the connection.
Maps_rbl_reject_code specifies the rejected return status code (554 by default ).
Check_sender_access maptype: mapname
Search for a maptype database named mapname. You can match the sender's email address, name, domain, and parent domain. For more information about database access, see the appendix below.
Reject_non_fqdn_sender
Deny that the domain of the sender's email is not in the FQDN format.
Non_fqdn_reject_code specifies the rejected return status code (504 by default ).
Reject_sender_login_mismatch
Deny the connection between the username and SASL username that the sender matches in $ smtpd_sender_owner_maps.
D. rcpt to Command filtering (recipient address restriction)
After the mail from command, you must use the rcpt to command TO specify the MAIL recipient. The receiver identity can be filtered and checked.
You can use the smtpd_recipient_restrictions command of Postfix to specify the filtering rules for this stage. Different from the preceding check commands. To avoid open forwarding, this command has the default value permit_mynetworks and reject_unauth_destination. In this phase, the available filtering rules include public rules and smtpd_client_restrictions rules, smtpd_helo_restrictions rules, and smtpd_sender_restrictions rules:
Permit_auth_destination
Connections that can be sent to default forwarding and receive by default are allowed.
By default, Postfix Forwards the following Emails:
Emails sent from $ mynetworks addresses
Email sent to the domain in $ relay_domains or its subdomain. But it cannot contain mail routes (such as user @ elsewhere@domain.tld ).
By default, Postfix receives emails whose final delivery targets meet the following conditions:
Target at $ inet_interfaces
Target at $ mydestinations
The target is in $ virtual_alias_domains
The target is in $ virtual_mailbox_domains
Reject_unauth_destination
Deny connections that are not sent to the default forwarding and receive by default.
Relay_domain_reject_code specifies the rejected return status code (554 by default ).
Permit_mx_backup
Allows you to receive emails from the MX address where the local host is the mail delivery target. But it cannot contain mail routes (such as user @ elsewhere@domain.tld ).
Check_recipient_access maptype: mapname
Search for a maptype database named mapname. You can match the email address, name, domain, and parent domain of the recipient's email. For more information about database access, see the appendix below.
Check_recipient_maps
Reject connections whose receiver does not match the following list:
$ Local_recipient_maps ($ mydestinations and $ inet_interfaces)
The empty $ local_recipient_maps and $ local_recipient_maps indicate that the receiver address is not filtered.
Postfix performs the check_recipient_maps check at the end of the receiver check list by default.
Reject_unknown_recipient_domain
Deny the connection of the recipient's email domain without the dns a record or MX record.
Unknown_address_reject_code specifies the rejected return Status Code (the default value is 450 ). When a temporary error occurs during DNS query (such as query timeout), 450 is always returned.
Reject_rhsbl_recipient domain. tld
Deny the connection of the recipient's email domain to the RHSBL blacklist. By checking whether a domain name exists in the RHSBL of domain. tld, you can determine whether the client is included in the real-time domain. tld blacklist and decide whether to accept the connection.
Maps_rbl_reject_code specifies the rejected return status code (554 by default ).
Reject_non_fqdn_recipient
The domain of the recipient's email is rejected because it is not in the FQDN format.
Non_fqdn_reject_code specifies the rejected return status code (504 by default ).
Permit_sasl_authenticated
Which of the following statements can be used for SASL authentication? Mü? The SMTP authentication function implemented by the ASL Protocol (including SASL1 and SASL2) needs to be compiled into SASL support when compiling Postfix, and set smtpd_sasl_auth_enable to yes in main. cf. For SASL authentication and how to implement SASL authentication in Postfix, see the appendix below. SASL authentication can be used to send emails to roaming users. It is an important way to disable Open-Relay.
Check_recipient_access regexp:/etc/postfix/recipient. re,
Reject_rbl_client relays.ordb.org,
Reject_rbl_client list.dsbl.org,
Reject_rbl_client sbl.spamhaus.org,
Reject_rbl_client blackholes. easynet. nl,
Reject_rhsbl_client dsn.rfc-ignorant.org,
Permit
Note that check for reject_non_fqdn _ * And reject_unknown _ * may result in failure to send emails to machines whose host names are not properly resolved. In addition, you can add warn_if_reject to the rule list header before applying this rule.
2. Multi-Stage filtering and single-stage Filtering
Because some defective email programs on windows do not process the reject status code sent back before the rcpt to Command, the Postfix will not be disconnected immediately after matching the deny rule, instead, it is disconnected after the rcpt to command is processed. You can set smtpd_delay_reject to no to immediately send a denial of status code to disconnect (yes by default ).
Depending on whether smtpd_delay_reject is set to yes or no, Postfix filtering can be implemented in two forms: Multi-Stage filtering and single-stage filtering.
A. Multi-Stage Filtering
When smtpd_delay_reject is set to yes, filtering is performed in multiple stages. For example, even if the connection is determined to be rejected in the previous substage, but the connection is delayed, the substage will be filtered, if the connection is allowed again in the substage, the rejection result of the previous substage will be overwritten.
In terms of results, this is equivalent to all the defined filtering rules regardless of the filtering results of the previous substage. So we call it multi-stage filtering. The logical model is as follows:
"|" Indicates that if a rule has a return value (that is, a match is performed, whether it returns permit or reject), the subsequent rule checks in this substage will not be performed.
B. Single-Stage Filtering
When the smtpd_delay_reject option is set to no, it is equivalent to concatenating the filtering rules of these four sub-stages into a single list of filtering rules in sequence. For example, if the connection is determined to be denied at a certain stage, the connection will be immediately rejected without processing the subsequent rules and the subsequent sub-phase rules.
From the results, this is equivalent to a rule that matches, then the subsequent rules and sub-stages are all short-circuited, just as there is only one sub-stage check. So we call it single-stage filtering. The logical model is as follows:
"|" Indicates that if a rule or sub-stage has a return value (that is, a match is performed, whether permit or reject is returned) then, the subsequent rules and sub-phase checks of this sub-phase will not be performed.
In single-stage filtering, because smtpd_recipient_restrictions can accept all pre-data filtering rules, all filtering rules are usually put here. Note that in single-stage filtering, all filtering rules that are listed in the front are first processed and short circuits are formed. For example, if you have applied the RBL service in smtpd_client_restrictions, but there is an address in RBL that you want to receive emails from there, there is no chance to check the sender's address. The solution is to perform a check_sender_access in smtpd_sender_restrictions (or smtpd_recipient_restrictions) and then perform RBL checks.
Ii. Post-Data Filtering
Sometimes it is not enough to judge whether an email is a spam email simply by sending the mail data. Further, you can determine whether the email is spam or not based on the information contained in the email data and decide how to handle it. Although filtering after the SMTP session has completed receiving data does not save the wasted bandwidth and processing capability, however, this reduces the space occupied by spam and the amount of effort wasted by users to delete spam, in addition, some popular email-based worms also reduce the possibility of user errors and continue to spread.
Post-data filtering is generally divided into header filtering and body filtering.
1. mail header Filtering
To put it simply, in an SMTP session, the DATA sent by the DATA command is separated by a blank line. The preceding part is called the header, and the following part is called the body. Generally, there are three types of headers in an email:
Primary email header
MIME header (including those after the multiple-part separator strings in the primary message header)
Header of the email included in the email
You can configure the header filter using the following Configuration:
Head_checks = maptype: mapname
It matches all three headers.
Mime_head_checks = maptype: mapname
It only matches the MIME header.
Nested_head_checks = maptype: mapname
It only matches the header of the included email.
There are two types of header filter templates: ISO standard regular expressions regexp and Perl Compatible Regular Expressions pcre. The two have some syntax differences and can be used either. The format of the filter rule in the filter template is as follows:
/Mode expression/Action
A pattern expression is an expression written in regexp or pcre to match the mail header.
Actions are as follows (they are not exactly the same as those supported in accessing the database, for example, they do not support [45] NN, numbers, DUNNO, and rules ):
REJECT [text]
Reject the email. The optional message is sent to the sender and recorded in maillog.
OK
No other matching rules will be processed for this header line, and the next header will be processed.
IGNORE
Delete the header line from the header. It is often used to delete certain header rows, such as Received.
WARNING [text]
Record the header line and optional messages to maillog. It is often used to test filtering rules.
HOLD [text]
Put the email in the hold queue, and record the header line and optional messages to maillog. Emails placed in the hold queue can be viewed using the postcat command, or deleted or submitted using postsuper.
DISCARD [text]
After successfully receiving the email, the email is quietly discarded, and the header line and optional message are recorded in maillog.
FILTER transport: nexthop
Send the email to a Mail Filter for processing.
In addition, when processing Subject, the Chinese (8-bit encoding) will be encoded as MIME or UUENCODE. Please perform the corresponding conversion.
2. Body Filtering
The body is the content of the mail except the primary mail header (including the MIME header, but the multi-row MIME header is processed as multiple single rows ). Body filtering usually does not check all the bodies. It only checks the size specified by body_checks_max_size (in bytes, the default value is 50 K ). Body filtering is performed on rows. for ultra-long rows, only the length specified by line_length_limi is checked (the default value is 2048 bytes ).
You can configure the email body filter using the following Configuration:
Body_checks = maptype: mapname
The mail body filter template is the same as the mail header filter template.
Iii. Appendix
1. Access the database
Database Access is a database that uses Postfix to determine whether to reject or accept emails. You can access the database to reject or receive specific host names, domain names, network addresses, and email addresses.
Generally, database access is a db or dbm HASH file generated by the postmap command from a text file input. There are also other databases using NIS, LDAP, SQL, and regular expressions. They work in the same way as HASH files, but do not need to be generated using postmap.
The database format is as follows:
Pattern expression action
When a pattern expression is matched, the corresponding action is triggered.
Empty rows in the database and rows starting with "#" are ignored. The row that starts with a space is the last row.
A. Email Address
A non-regular expression is used to indicate the mail address in the following format:
User@domain.tld
Match a specific email address
Domain. tld
Match the domain of a specific email. If smtpd_access_maps (default) is specified in parent_domain_matches_subdomains, the domain's subdomains are also matched; otherwise, the. doamin. tld format is used (note the previous point) to match the subdomains separately.
User @
Match all local parts (email user name) to the user's email address
<>
No email address is matched. This value is specified through smtpd_null_access_lookup_key.
B. Host Name and Address
A non-regular expression is used to indicate the host name and address in the following format:
Domain. tld
Match the domain of a specific email. If smtpd_access_maps (default) is specified in parent_domain_matches_subdomains, the domain's subdomains are also matched; otherwise, the. doamin. tld format is used (note the previous point) to match the subdomains separately.
Net. work. addr. ess
Net. work. addr
Net. work
Net
Match the network address. Note that CIDR (network/netmask format) is not supported.
C. Action
Database Access supports the following actions:
[45] NN text
This email is rejected and a digital denial status code and message are returned.
REJECT [text]
This email is rejected and a denial status code and message are returned. If no message is specified, a common message is returned.
OK
Accept the email.
Number
Like OK, accept the email.
DUNNO
Skip this rule and proceed with the following rule.
HOLD [text]
Put the email in the hold queue and record optional messages or common messages to maillog. Emails placed in the hold queue can be viewed using the postcat command, or deleted or submitted using postsuper.
DISCARD [text]
After successfully receiving the email, the email is quietly discarded and optional messages or common messages are recorded in maillog.
FILTER transport: nexthop
Send the email to a Mail Filter for processing.
UCE rules
Apply UCE rules, such as permit, reject_unauth_destination, and smtpd_restriction_classes.
2. SMTP authentication (SASL authentication)
As described above, roaming users must use the mail service through SMTP authentication. By default, Postfix does not support the SASL protocol, that is, it does not support SMTP authentication. You must specify the SASL library location and enable the SASL authentication function to support SMTP authentication. The following uses Postfix-2.0.13 and Cyrus-Sasl-2.1.1 as an example to describe how to use SMTP authentication.
First download Postfix-2.0.13 and the Cyrus-Sasl-2.1.1, and install the cyrus-sasl-2.1.1. By default, cyrus-sasl is installed under/usr/local. Its Library is under/usr/local/lib, and its header file is under/usr/local/include/sasl.
Then unpack the source code package of Postfix-2.0.13 and compile it with the following command:
% Make tidy
% Make makefiles CCARGS = "-DUSE_SASL_AUTH-I/usr/local/include/sasl"
AUXLIBS = "-L/usr/local/lib-lsasl2"
If necessary, you can add other compilation options, such as MySQL support.
After compilation, install the SDK, modify/etc/postfix/main. cf, and add the following Configuration:
Smtpd_sasl_auth_enable = yes
To enable SASL authentication, and then add the permit_sasl_authenticated rule to smtpd_recipient_restrictions:
To allow users who have passed SASL authentication to send emails. You can also add other required rules here.
Modify/usr/local/lib/sasl2/smtpd. conf (if not, create one) and set the authentication method you need, such as auxprop, pwcheck, and saslauthd. This depends on your specific needs.
After configuring Postfix, restart Postfix.
Then, you can use the mail client that supports SMTP authentication to authenticate and send emails. You can also use Telnet to test whether your SMTP authentication is successful.
For more details about SASL authentication, see the SASL_README file in the README_FILES directory of the Postfix source code package.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
