Postfix submitting email not in Recipients List
-
I'm running v2 Postfix on 2.1.5 i386 and I've noticed that email for users not in the Recipients List on the PF Recipients tab are still being forwarded to the iRedMail server and are being refused by it. This puts info into the 550 5.1.1 rejection that I'd like to keep hidden. Is this expected behaviour or did I miss a setting?
Thanx,
Garth -
A bit of an update. PF is not actually sending the email as previously stated. What it is doing is verifying the creds against the email server instead of rejecting them outright when the user is not in the Recipients list. I have another pfSense/Postfix box that is doing it correctly so I'll compare the settings between the two to see what's different.
Helpful pointers still appreciated.
Thanx,
Garth -
Probably "basic" versus "strong" selected in Header verification under the Anti-spam tab.
Strong inserts reject_unverified_recipient under smtp_recipient_restrictions
-
Thanx for reply. I checked and Strong is selected. Below is a sanitized telnet 25 session with the PF server showing the response to a nonexistant user is coming from the internal mail server. This may be correct but I seem to remember that the internal email server was not contacted until after all of the checks were made. Is my memory incorrect?
garthk@myws:~$ telnet 1.1.1.1 25
Trying 1.1.1.1…
Connected to 1.1.1.1.
Escape character is '^]'.
220 mail.abc.net ESMTP Postfix
helo abc.com
250 mail.abc.net
mail from: garthk@abc.com250 2.1.0 Ok
rcpt to: joe@abc.net550 5.1.1 joe@abc.net: Recipient address rejected: undeliverable address: host 10.10.10.10[10.10.10.10] said: 550 5.1.1 joe@abc.net: Recipient address rejected: User unknown in virtual mailbox table (in reply to RCPT TO command)
quit
221 2.0.0 Bye
Connection closed by foreign host.Below is a section from a backup showing the settings for PF:
<package><name>Postfix Forwarder</name>
<website>http://www.postfix.org/</website>
<descr>It can do first and second line antispam combat before sending incoming mail to local mail servers.<br />
Postfix can also detect zombies, check RBLS, SPF, seach ldap for valid recipients and use third part antispam engines like policyd and mailscanner for better antispam solution.]]></descr>
<category>Services</category>
<pkginfolink>https://forum.pfsense.org/index.php/topic,40622.0.html</pkginfolink>
<config_file>https://packages.pfsense.org/packages/config/postfix/postfix.xml</config_file>
<depends_on_package_base_url>https://files.pfsense.org/packages/8/All/</depends_on_package_base_url>
<depends_on_package>postfix-2.10.2,1.tbz</depends_on_package>
<depends_on_package>perl5-5.16.3_4.tbz</depends_on_package>
<depends_on_package_pbi>postfix-2.10.2-i386.pbi</depends_on_package_pbi>
<version>2.10.2 pkg v.2.3.9</version>
<status>Release</status>
<required_version>2.1</required_version>
<configurationfile>postfix.xml</configurationfile>
<build_port_path>/usr/ports/mail/postfix</build_port_path>
<build_options>WITH_PCRE=true;WITH_SPF=true;WITH_SASL2=true;WITH_TLS=true</build_options></package>
<postfix><config><enable_postfix>on</enable_postfix>
<inet_protocol>ipv4</inet_protocol>
<enabled_interface>wan,lo0</enabled_interface>
<message_size_limit><process_limit><maincf><log_to>maillog</log_to>
<update_sqlite>01min</update_sqlite>
<debug_list><debug_level>2</debug_level>
<widget_days>3</widget_days>
<widget_size>200000000</widget_size></debug_list></maincf></process_limit></message_size_limit></config></postfix>
<postfixdomains><config><row><domain>abc.net</domain>
<mailserverip>10.10.10.10</mailserverip></row></config></postfixdomains>
<postfixrecipients><config><freq>30m</freq>
<enable_ldap><row><dc><cn><username><password></password></username></cn></dc></row>
<enable_url><custom_url><custom_recipients>cG9zdG1hc3RlckBnZGNqay5uZXQgT0sNCmdhcnRoa0BnZGNqay5uZXQgT0sNCmNhcm9sa0BnZGNqay5uZXQgT0s=</custom_recipients></custom_url></enable_url></enable_ldap></config></postfixrecipients>
<postfixantispam><config><header_check>strong</header_check>
<reject_unknown_helo_hostname>on</reject_unknown_helo_hostname>
<zombie_blocker>enforce</zombie_blocker>
<greet_time>2,6s</greet_time>
<after_greeting>postscreen_bare_newline_enable,postscreen_disable_vrfy_command,postscreen_non_smtp_command_enable,postscreen_pipelining_enable,postscreen_greet_check</after_greeting>
<soft_bounce>postscreen</soft_bounce>
<anvil>postscreen</anvil>
<rbl_servers>zen.spamhaus.org</rbl_servers>
<rbl_threshold>2</rbl_threshold>
<postfix_spf>reject_spf_invalid_sender</postfix_spf>
<antispam_enabled><hold_mode>auto</hold_mode>
<antispam_software>mailscanner</antispam_software>
<antispam_location></antispam_location></antispam_enabled></config></postfixantispam><dhcrelay><dhcrelay6>Let me know if I missed something.
Thanx,
Garth</dhcrelay6></dhcrelay>/joe@abc.net/joe@abc.net/joe@abc.net/garthk@abc.com -
Your main.cf files would be more interesting to compare.
Reading this:
. . . recipient address verification is useful to block mail for undeliverable recipients on a mail relay host that does not have a list of all valid recipient addresses
I don't understand why your mail server is being queried at all.
-
Here is the main.cf. I've searched on the suspicious entries but have found nothing that looks wrong.
Thanx,
Garth/usr/pbi/postfix-i386/etc/postfix/main.cf
#main.cf
#Part of the Postfix package for pfSense
#Copyright (C) 2010 Erik Fonnesbeck
#Copyright (C) 2011-2013 Marcello Coutinho
#All rights reserved.
#DO NOT EDIT THIS FILEmynetworks = /usr/pbi/postfix-i386/etc/postfix/mynetwork_table
mynetworks_style = host
access_map_reject_code= 554
access_map_defer_code = 451
unverified_recipient_reject_code = 550
unknown_client_reject_code = 550
unknown_hostname_reject_code = 550relay_domains = abc.net
transport_maps = hash:/usr/pbi/postfix-i386/etc/postfix/transport
local_recipient_maps =
relay_recipient_maps = hash:/usr/pbi/postfix-i386/etc/postfix/relay_recipients
mydestination =
mynetworks_style = host
message_size_limit = 10240000
default_process_limit = 100
disable_vrfy_command = yes
strict_rfc821_envelopes = yes#Just reject after helo,sender,client,recipient tests
smtpd_delay_reject = yesDon't talk to mail systems that don't know their own hostname.
smtpd_helo_required = yes
smtpd_helo_restrictions = check_helo_access pcre:/usr/pbi/postfix-i386/etc/postfix/helo_check,
reject_unknown_helo_hostname,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
permitsmtpd_sender_restrictions = reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unauth_pipelining,
reject_multi_recipient_bounce,
permitAllow connections from specified local clients and strong check everybody else.
smtpd_client_restrictions = permit_mynetworks,
reject_unauth_destination,
check_client_access pcre:/usr/pbi/postfix-i386/etc/postfix/cal_pcre,
check_client_access cidr:/usr/pbi/postfix-i386/etc/postfix/cal_cidr,
reject_unknown_client_hostname,
reject_unauth_pipelining,
reject_multi_recipient_bounce,
permitsmtpd_recipient_restrictions = permit_mynetworks,
reject_unauth_destination,
reject_unauth_pipelining,
check_client_access pcre:/usr/pbi/postfix-i386/etc/postfix/cal_pcre,
check_client_access cidr:/usr/pbi/postfix-i386/etc/postfix/cal_cidr,
check_sender_access hash:/usr/pbi/postfix-i386/etc/postfix/sender_access,
reject_non_fqdn_helo_hostname,
reject_unknown_recipient_domain,
reject_non_fqdn_recipient,
reject_multi_recipient_bounce,
reject_unverified_recipient,
reject_spf_invalid_sender,
permitinet_protocols = ipv4
inet_interfaces = 1.2.3.4,127.0.0.1
postscreen_greet_wait = ${stress?2}${stress:6}s
postscreen_disable_vrfy_command = yes
postscreen_non_smtp_command_enable = yes
postscreen_non_smtp_command_action = enforce
postscreen_pipelining_enable = yes
postscreen_pipelining_action = enforce
postscreen_bare_newline_enable = yes
postscreen_bare_newline_action = enforce
postscreen_greet_action = enforce
postscreen_access_list = permit_mynetworks,
cidr:/usr/pbi/postfix-i386/etc/postfix/cal_cidr
postscreen_dnsbl_action= enforce
postscreen_blacklist_action= enforce
postscreen_dnsbl_sites=zen.spamhaus.org
postscreen_dnsbl_threshold=2 -
That looks pretty much the same as mine. I don't use a valid recipients list, though, so postfix always queries the mail server if it hasn't got a cached positive or negative response from there before. Those cached entries do expire after a time.
Is this the config for the one that's querying your mail server? Maybe your other server is just not receiving many emails for address responses that aren't cached.
Unfortunately, from what I've read, I don't think there is any way to stop the queries completely but they should be relatively rare, unless you are seeing lots of spammers who get past the usual postscreen checks.I suspect that reject_unverified_recipient should be reject_unlisted_recipient in main.cf.
-
I did a little experiment:
Built a table of valid recipients from my mail server.
Replaced reject_unverified_recipient with reject_unlisted_recipient in main.cf and reloaded postfix
I get the error (which is to be expected because I didn't rebuild relay_recipients.db):
warning: database /usr/pbi/postfix-amd64/etc/postfix/relay_recipients.db is older than source file /usr/pbi/postfix-amd64/etc/postfix/relay_recipients
However, I don't get the double-bounce query to the mail server with this configuration.
So it looks as though, when you have a valid recipients list, reject_unlisted_recipient should be in main.cf, rather than reject_unverified_recipient.
-
Good work and I agree. I changed from unverified to unlisted in main.cf and the unknown user is rejected immediately by pfSense/Postfix rather than asking the email server to verify. Much better.
Now, how long will the change remain in place before the main.cf gets regenerated? There is a cap warning about not editing near the top of the file. Should this be reported as a bug?
Thanx,
Garth -
I'm hoping marcelloc will notice this thread.
Not that I think it's a really a bug. There are so many config options in postfix that I'm not surprised he would have had to make some tough choices about how to manage certain things through the GUI.
I suspect any save through the GUI or reinstall of the package would wipe out the change.