Score:1

Why does all email, including email that is rejected, get processed by the milter?

il flag

I've configured postfix to use a milter.

Unfortunately, it seems that all email goes through the milter, even email that is rejected with "User unknown" messages or email rejected by the check_policy_service setting in smtpd_check_recipients.

This is causing problems when we get mail bombed because our milter can't keep up. Have I misconfigured something? Or is this by design?

Here's my main.cf:

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2



# TLS parameters
smtpd_tls_cert_file=/etc/letsencrypt/live/a.mx.xxxxx.org/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/a.mx.xxxxx.org/privkey.pem
smtpd_tls_security_level=may

smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache


smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = a.mx.xxxxx.org
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname, mailmx001.xxxxx.org, localhost.xxxxxt.org, , localhost
relayhost = filter.xxxxx.org
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
# BEGIN ANSIBLE MANAGED BLOCK
relay_domains = hash:/etc/postfix/relay-domains
relay_recipient_maps = hash:/etc/postfix/relay-recipient-maps
virtual_alias_domains = hash:/etc/postfix/virtual-alias-domains
virtual_alias_maps = pcre:/etc/postfix/virtual-alias-maps
# END ANSIBLE MANAGED BLOCK
# BEGIN ANSIBLE MANAGED BLOCK MX SETTINGS
smtpd_sender_restrictions =
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
  permit
smtpd_recipient_restrictions =
  # postfwd
  check_recipient_access hash:/etc/postfix/reject-abandoned-mailboxes,
  check_recipient_access hash:/etc/postfix/reject-over-quota-mailboxes,
  # Defer email sent to unverified domains, unless it's our
  # special email address for verifying the domain.
  check_recipient_access hash:/etc/postfix/defer-unverified-domains,
  permit_mynetworks,
  reject_unauth_pipelining,
  reject_non_fqdn_recipient,
  reject_invalid_hostname,
  reject_unknown_recipient_domain,
  reject_unauth_destination,
  check_policy_service inet:127.0.0.1:10040
# END ANSIBLE MANAGED BLOCK MX SETTINGS
# BEGIN ANSIBLE MANAGED BLOCK MX POSTSCREEN PRE 220
postscreen_access_list = permit_mynetworks,
  cidr:/etc/postfix/postscreen_xxxxx.cidr,
  cidr:/var/lib/postwhite/postscreen_spf_whitelist.cidr
postscreen_blacklist_action = enforce
postscreen_greet_action = enforce
# Any provider listed on list.dnswl.org passes automatically. This allows us to skip
# the deep inspection POST 220 tests which defer clients that pass.
postscreen_dnsbl_whitelist_threshold = -1
postscreen_dnsbl_sites = list.dnswl.org*-1
# END ANSIBLE MANAGED BLOCK MX POSTSCREEN PRE 220
# BEGIN ANSIBLE MANAGED BLOCK MX POSTSCREEN POST 220
postscreen_pipelining_enable = yes
postscreen_non_smtp_command_enable = yes
postscreen_bare_newline_enable = yes
postscreen_pipelining_action = enforce
postscreen_non_smtp_command_action = enforce
postscreen_bare_newline_action = enforce
# END ANSIBLE MANAGED BLOCK MX POSTSCREEN POST 220
# BEGIN ANSIBLE MANAGED BLOCK COMMON
smtpd_tls_CApath = /etc/ssl/cert
message_size_limit = 26214400 
enable_long_queue_ids = yes
# END ANSIBLE MANAGED BLOCK COMMON
smtpd_milters = inet:localhost:8899
Score:2
za flag

It's basically answered in the MILTER README, but you need to understand what Milter is.

For every protocol command, Postfix runs is own checks available so far, and if the verdict is not "reject" yet, it will send the command to a first milter; if it doesn't reject the second milter, and so on. Then, if milters did not reject, the next command processed in the same way. See the milter API description: an application can register a callback for a connection, callback to process HELO, etc.

This doesn't mean milter always processes the body of the message with heavy checks. Contrary is true: the message (or connection) is rejected as early as possible. If milter or Postfix (a policy service or whatever) rejects the command on some early stage (which often happens at RCPT TO because of smtpd_delay_reject is enabled by default), it won't bother to get a body from the peer and therefore won't pass it to the milter. But all commands that were exchanged prior to the rejection are passed to a milter.

From your config I see most rejection happens in smtpd_recipient_restrictions, that's exactly the RCPT TO stage; this means, if the message is rejected by the policy service at the end, the milter will receive and process the following: IP connected, HELO string, envelope FROM, and then it will receive message abort.

So there is a requirement for any milter application: it should be light on those commands.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.