Postfix check_recipient_mx_access not work

us flag

I have configured the check_recipient_mx_access option in Postfix in order to reject emails to misspelled domains. We have a system that sends air flight confirmations and many times users write the contact email account incorrectly.

The documentation indicates the following

check_recipient_mx_access type:table
        Search the specified access(5) database for the MX hosts for the
        RCPT TO domain, and execute the corresponding action. If no MX
        record is found, look up A or AAAA records, just like the Postfix
        SMTP client would. Note: a result of "OK" is not allowed for safety
        reasons. Instead, use DUNNO in order to exclude specific hosts from
        denylists. This feature is available in Postfix 2.1 and later.

My configuration is as follows:

smtpd_recipient_restrictions = reject_invalid_hostname,
                               check_client_access hash:/etc/postfix/rbl_override,
                               check_recipient_mx_access hash:/etc/postfix/bogus_mx,

The following rule is added to the file bogus_mx: REJECT

when I try to send an email via telnet the same is not rejected:

root@mailserver:~# telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 ESMTP Postfix (Debian/GNU)
ehlo me
250-SIZE 10240000
250 DSN
mail from: [email protected]
250 2.1.0 Ok
rcpt to: [email protected]
250 2.1.5 Ok
354 End data with <CR><LF>.<CR><LF>
Subject: Test Telnet
Hello dear,
250 2.0.0 Ok: queued as D161160E5D
221 2.0.0 Bye
Connection closed by foreign host.

System information:

root@mailserver:/etc/postfix# postconf mail_version
mail_version = 2.11.3

No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.11 (jessie)
Release:        8.11
Codename:       jessie

Any ideas??


id flag
Did you try to add the "" to the bogus_mx table instead of its IP? This is the way I understand the docs. And also move the `check_recipient_mx_access` before the `permit_mynetworks`
Nikita Kipriyanov avatar
za flag
Probably it was *permit*ted before it even got down to this `check_recipient_mx_access`. It may have been permitted by `permit_mynetworks`, or `check_client_access` result. To debug, add your test client IP address to the list `debug_peer_list`, it will log *extended* debug for connections from that client (very verbose), with details for each performed check (each comparison will be logged). That will let you determine where it permitted the mail.
Nikita Kipriyanov avatar
za flag
Having said that, what you will do if someone really registered the valid domain `` and someone really will need to send mail there from your server? You deliberately chose some names as "wrong" or "misspelled" without any valid reason behind it, just because "you see it that way" (and you won't be able to catch all possible misspellings anyway).
Nikita Kipriyanov avatar
za flag
Also, instead of receiving the concrete error "the recipient domain does not exists" (if it does not exists), your users will get generic "client_recipient_mx_access denied" for some misspelled domains, without any clue *what exactly* was wrong. That's bad things.
us flag
I activated the debug, I don’t think postfix not read the rule: Any ideas?
Nikita Kipriyanov avatar
za flag
I don't see a place where it evaluates `smtpd_recipient_restrictions`. However, I noticed you connected from ``, which is likely in the `mynetworks`, so your `permit_mynetworks` will permit this message leaving no chance for checking everything below, as I explained above.
jp flag
Also, Debian 8 has been EOL since June 2018, the LTS has ended on June 2020, and Postfix is not in the list of ELTS packages from Freexian. It is time to upgrade.

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.