[opensuse] 10.3 how to speed up smtp performance
Listmates (Sandy), I have built a fresh 10.3 server, but smtp performance seems slow. Are there any tips or tricks to improve the mail sending performance. Here are the current settings: root@bonza:/home/david # postconf -n alias_maps = hash:/etc/aliases biff = no canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix debug_peer_level = 2 defer_transports = disable_dns_lookups = no disable_mime_output_conversion = no html_directory = /usr/share/doc/packages/postfix/html inet_interfaces = all inet_protocols = all mail_owner = postfix mail_spool_directory = /var/mail mailbox_command = /usr/bin/procmail -a "$EXTENSION" mailbox_size_limit = 0 mailbox_transport = mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient masquerade_domains = masquerade_exceptions = root message_size_limit = 10240000 mydestination = $myhostname, localhost.$mydomain, $mydomain, guillorylaw.com, rankinlawfirm.com, drrankin.com, txuovercharges.com, bertinlawoffice.com, darrenbertin.com, tannergarth.com myhostname = bonza.rbpllc.com mynetworks_style = subnet myorigin = $mydomain newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix/README_FILES relayhost = relocated_maps = hash:/etc/postfix/relocated sample_directory = /usr/share/doc/packages/postfix/samples sender_canonical_maps = hash:/etc/postfix/sender_canonical sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtp_sasl_auth_enable = no smtp_use_tls = no smtpd_banner = $myhostname ESMTP $mail_name ($mail_version) (Rankin Law Firm, PLLC) smtpd_client_restrictions = check_client_access cidr:/etc/postfix/client_check.cidr, reject_rbl_client relays.ordb.org, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client list.dsbl.org smtpd_hard_error_limit = 3 smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, reject_non_fqdn_hostname smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access pcre:/etc/postfix/recipient_check.pcre smtpd_sasl_auth_enable = no smtpd_sender_restrictions = hash:/etc/postfix/access smtpd_use_tls = no strict_8bitmime = no strict_rfc821_envelopes = no transport_maps = hash:/etc/postfix/transport unknown_client_reject_code = 550 unknown_local_recipient_reject_code = 550 virtual_alias_domains = hash:/etc/postfix/virtual virtual_alias_maps = hash:/etc/postfix/virtual Which of these would affect or help smtp response time? Any tips would be appreciated. -- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
David C. Rankin wrote:
Listmates (Sandy),
I have built a fresh 10.3 server, but smtp performance seems slow. Are there any tips or tricks to improve the mail sending performance.
There aren't going to be any magic kernel settings to make mail-handling faster. The reason is that mail handing is NOT a cpu-bound task, it's disk-I/O and network-I/O-bound Therefore, the way to improve the process of a mail server is to 1: use RAID disk-striping 2: Improve your network connectivity. Install one or more 4-port Ethernet cards. Connect the server to several subnets directly (but beware how you do this, or else your mail server will suddenly become a router and get a flood of IP traffic) so that incoming mail can come in on multiple ethernet ports simultaneously. Also: Add memory until the motherboard is maxed-out. In almost all cases, adding memory is the cheapest, and most helpful to ALL processes running on a server (for example, more memory reduces both the amount of filesystem I/O AND swap disk activity)
Here are the current settings:
root@bonza:/home/david # postconf -n alias_maps = hash:/etc/aliases biff = no canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix debug_peer_level = 2 defer_transports = disable_dns_lookups = no disable_mime_output_conversion = no html_directory = /usr/share/doc/packages/postfix/html inet_interfaces = all inet_protocols = all mail_owner = postfix mail_spool_directory = /var/mail mailbox_command = /usr/bin/procmail -a "$EXTENSION" mailbox_size_limit = 0 mailbox_transport = mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient masquerade_domains = masquerade_exceptions = root message_size_limit = 10240000 mydestination = $myhostname, localhost.$mydomain, $mydomain, guillorylaw.com, rankinlawfirm.com, drrankin.com, txuovercharges.com, bertinlawoffice.com, darrenbertin.com, tannergarth.com myhostname = bonza.rbpllc.com mynetworks_style = subnet myorigin = $mydomain newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix/README_FILES relayhost = relocated_maps = hash:/etc/postfix/relocated sample_directory = /usr/share/doc/packages/postfix/samples sender_canonical_maps = hash:/etc/postfix/sender_canonical sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtp_sasl_auth_enable = no smtp_use_tls = no smtpd_banner = $myhostname ESMTP $mail_name ($mail_version) (Rankin Law Firm, PLLC) smtpd_client_restrictions = check_client_access cidr:/etc/postfix/client_check.cidr, reject_rbl_client relays.ordb.org, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client list.dsbl.org smtpd_hard_error_limit = 3 smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, reject_non_fqdn_hostname smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access pcre:/etc/postfix/recipient_check.pcre smtpd_sasl_auth_enable = no smtpd_sender_restrictions = hash:/etc/postfix/access smtpd_use_tls = no strict_8bitmime = no strict_rfc821_envelopes = no transport_maps = hash:/etc/postfix/transport unknown_client_reject_code = 550 unknown_local_recipient_reject_code = 550 virtual_alias_domains = hash:/etc/postfix/virtual virtual_alias_maps = hash:/etc/postfix/virtual
Which of these would affect or help smtp response time? Any tips would be appreciated.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Aaron Kulkis wrote:
David C. Rankin wrote:
Listmates (Sandy),
I have built a fresh 10.3 server, but smtp performance seems slow. Are there any tips or tricks to improve the mail sending performance.
There aren't going to be any magic kernel settings to make mail-handling faster. The reason is that mail handing is NOT a cpu-bound task, it's disk-I/O and network-I/O-bound
Your advice isn't wrong, but doesn't really address the issue at hand. First you check your software configuration, and only then you throw metal and money at the problem. In most cases the the configuration is less than optimal, and investing in hardware ist not going to solve the problem if the number of smtp client processes is not adjusted. You simply waste -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Aaron Kulkis escribió:
Therefore, the way to improve the process of a mail server is to...
...Mount the mail spool with the "noatime" option .. ;-) -- "The only thing that interferes with my learning is my education." - Albert Einstein Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2008-01-07 at 06:36 -0300, Cristian Rodríguez wrote:
Aaron Kulkis escribió:
Therefore, the way to improve the process of a mail server is to...
...Mount the mail spool with the "noatime" option .. ;-)
Hum! Traditionally, it was to be mounted "sync", no less... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHggJltTMYHG2NR9URAjheAJ9FpNn6AkwQtu847wvPRJGwtn8PugCcCGUy oLFhomWWMpEeyGTuhFr6l/E= =+3W5 -----END PGP SIGNATURE-----
David C. Rankin escribió:
Which of these would affect or help smtp response time? Any tips would be appreciated.
Care to explain where specifically the performance problem lies ? it takes too long to deliver ? the remote SMTP clients hang while talking to your server ? how much mail are you sending ? any evidence on the logs ? is name resolution working correclty and at a decent speed ? -- "The only thing that interferes with my learning is my education." - Albert Einstein Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Cristian Rodríguez wrote:
David C. Rankin escribió:
Which of these would affect or help smtp response time? Any tips would be appreciated.
Care to explain where specifically the performance problem lies ? it takes too long to deliver ? the remote SMTP clients hang while talking to your server ? how much mail are you sending ? any evidence on the logs ? is name resolution working correclty and at a decent speed ?
Sorry guys, Messages ~1000 per day, but that isn't the problem. The problem is that when a user hits 'send' the mail take _60_ seconds to get across the server. The mailer just sits there "sending... sending..." the whole time. The 60 seconds suggests a screwup in configuration on my part and a 60 second timeout somewhere, but I don't know what to check. -- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
David C. Rankin wrote:
Messages ~1000 per day, but that isn't the problem. The problem is that when a user hits 'send' the mail take _60_ seconds to get across the server. The mailer just sits there "sending... sending..." the whole time. The 60 seconds suggests a screwup in configuration on my part and a 60 second timeout somewhere, but I don't know what to check.
Again, what does your name resolution look like? Does your smtp server have instant access to forward and backward resolution of all the lan clients? Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
David C. Rankin wrote:
Messages ~1000 per day, but that isn't the problem. The problem is that when a user hits 'send' the mail take _60_ seconds to get across the server. The mailer just sits there "sending... sending..." the whole time. The 60 seconds suggests a screwup in configuration on my part and a 60 second timeout somewhere, but I don't know what to check.
So, you have an internal client/server submission problem? This smacks like a dns resolution problem. All clients or only external/internal? Webmail or smtp client software? Firewall between client /server? What does the log say, starting from connect to? There are too many questions unanswered to give precise help. Here's a command line test: Check from client: "telnet ip.of.ser.ver 25" or "telnet name.of.ser.ver 25" (test both) - How log does it take, bevor the smtp banner appears? "ehlo client.full.name" - How long, bevor the Capabilities of the server are seen? "mail from:<sender@example.com>" - How long for the server to respond? "rcpt to:<recipient@another.example.com>" - How long for the server to respond? "data" - How long... Write some text lines here... [return] . [return] - How long for the server to respond? -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
David C. Rankin wrote:
Listmates (Sandy),
I have built a fresh 10.3 server, but smtp performance seems slow. Are there any tips or tricks to improve the mail sending performance. Here are the current settings:
<snip>
Which of these would affect or help smtp response time? Any tips would be appreciated.
How much mail traffic do you have? Is it hundreds of messages a day, thousands, tens of thousands? Your settings look fairly ordinary BTW, and postfix can do a lot of traffic out of the box, so... Is the server being taxed? What is the load average? Is it swapping? What is the typical mail queue size, and what is the average delay for smtp deliveries? In the absence of any other information, and if your box isn't actually being taxed, then my first suspicion is your dns resolution. If at all possible, using a slave dns server on the same box will help a lot. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
David C. Rankin wrote:
Listmates (Sandy),
I have built a fresh 10.3 server, but smtp performance seems slow. Are there any tips or tricks to improve the mail sending performance. Here
There are two sides to performant smtp delivery: - make sure to configure the server to utilize available hardware and bandwidth as best as possible + avoid network saturation, that will hinder answer packages to get through, if necessary, use traffic shaping + avoid smtp process exhaustion for internal and incoming transports - make sure to accomodate the expectations of the receiving servers as best as possible + squeaky clean dns records: matching forward and reverse dns + helo matches existing dns records + spf entry if you send a lot to microsoft accounts + domainkeys/dkim + register as postmaster to high-level destinations, most big providers have such a procedure to whitelist your server and for you to receive trouble tickets etc. + monitor bounces/rejects carefully, some destinations blacklist you temporarily if you cause too many rejections. Your database of addresses will be outdated faster than you can watch. + don't saturate the receiving servers, set appropriate limits for simultaneous parallel delivery. Configure a slow transport that only uses a few smtp processes for small sites. Most of the usual suggestions are the reversal of antispam settings. Using your own dns server or at least caching slave server has also been suggested. For high level mailservers a local dns server could speed up dns resolution a lot. The rest is your task to figure out for your local circomstances. Do you send newsletters (many mails occuring during a short time) or do you need to send continuously at a high level? Lots of big mails, varying sizes or only lots of small mail? Look at your log to find out if your server doesn't send as fast as possible of if the receiving servers delay delivery.
are the current settings:
root@bonza:/home/david # postconf -n alias_maps = hash:/etc/aliases biff = no canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix debug_peer_level = 2 defer_transports = disable_dns_lookups = no disable_mime_output_conversion = no html_directory = /usr/share/doc/packages/postfix/html inet_interfaces = all inet_protocols = all mail_owner = postfix mail_spool_directory = /var/mail mailbox_command = /usr/bin/procmail -a "$EXTENSION" mailbox_size_limit = 0 mailbox_transport = mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient masquerade_domains = masquerade_exceptions = root message_size_limit = 10240000 mydestination = $myhostname, localhost.$mydomain, $mydomain, guillorylaw.com, rankinlawfirm.com, drrankin.com, txuovercharges.com, bertinlawoffice.com, darrenbertin.com, tannergarth.com myhostname = bonza.rbpllc.com
The problem starts here: dig bonza.rbpllc.com ; <<>> DiG 9.4.1-P1 <<>> bonza.rbpllc.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42966 ^^^^^^^^ postconf -d smtp_helo_name smtp_helo_name = $myhostname So you are using an invalid helo name.
mynetworks_style = subnet
Better set this manually. If the Server has an official ip address you will invite your neighbor servers to use you as relay. If you don't have correct dns records, receiving servers may reject you, place additional restrictions like greylisting or in best case waste time on additional dns queries for blacklists, helo etc.
myorigin = $mydomain newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix/README_FILES relayhost = relocated_maps = hash:/etc/postfix/relocated sample_directory = /usr/share/doc/packages/postfix/samples sender_canonical_maps = hash:/etc/postfix/sender_canonical sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtp_sasl_auth_enable = no smtp_use_tls = no smtpd_banner = $myhostname ESMTP $mail_name ($mail_version) (Rankin Law Firm, PLLC) smtpd_client_restrictions = check_client_access cidr:/etc/postfix/client_check.cidr, reject_rbl_client relays.ordb.org, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client list.dsbl.org
Several problems: You don't exclude authenticated clients or clients in mynetworks. You are using a dead RBL (relays.ordb.org has gone the way of the dinosaurs).
smtpd_hard_error_limit = 3 smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, reject_non_fqdn_hostname smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access pcre:/etc/postfix/recipient_check.pcre smtpd_sasl_auth_enable = no smtpd_sender_restrictions = hash:/etc/postfix/access
Do you use /etc/postfix/access? If not, drop it from your config. In this case it would be a check_sender_access because it is placed in sender_restrictions. Pet peeve #1: don't use short cuts, always use the complete form. If you decide one day to move the check to smtpd_recipient_restrictions, it would suddenly become a check_recipient_access instead of a check_sender_access. Better to set up all checks in one class and disable the rest, it's much more transparent that way. smtpd_client_restrictions = smtpd_sender_restrictions = smtpd_sender_restrictions = smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient permit_mynetworks permit_sasl_authenticated reject_unauth_destination reject_unlisted_recipient # check_client_access hash:/etc/postfix/client_whitelist cidr:/etc/postfix/client_check.cidr check_recipient_access pcre:/etc/postfix/recipient_check.pcre reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, # consider using zen.spamhaus.org! reject_rbl_client sbl-xbl.spamhaus.org reject_rbl_client list.dsbl.org Pet peeve #2: cidr:/etc/postfix/client_check.cidr check_recipient_access pcre:/etc/postfix/recipient_check.pcre Can you tell me what kind of checks are in these files? Will you be able to tell me in half a year as well? Let's say, you only use it for blacklisting now, but some day you decide to whitelist someone and say "OK", and suddenly you enable him to use your server as relay, because you might have put the check before reject_unauth_destination. As long as you were only using it to reject clients it wouldn't matter, but whitelist a client and suddenly he can use you as relay. Whitelist a client before you check for valid recipients, and you risk to turn into a backscatter source. Consider using telling names for the checks: cidr:/etc/postfix/client_blacklist.cidr pcre:/etc/postfix/recipient_greylisting_enabled.pcre pcre:/etc/postfix/recipient_internal_only.pcre If necessary split the checks and create separate files for separate purposes (blacklisting/rejecting, whitelisting, filtering etc.), then you can easily place them at the correct place in the order of checks. The policy of your mail system is much more maintainable that way.
smtpd_use_tls = no strict_8bitmime = no strict_rfc821_envelopes = no transport_maps = hash:/etc/postfix/transport unknown_client_reject_code = 550 unknown_local_recipient_reject_code = 550 virtual_alias_domains = hash:/etc/postfix/virtual virtual_alias_maps = hash:/etc/postfix/virtual
Which of these would affect or help smtp response time? Any tips would be appreciated.
After you have fixed your dns settings, -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sandy Drobic wrote:
myhostname = bonza.rbpllc.com
The problem starts here: dig bonza.rbpllc.com
; <<>> DiG 9.4.1-P1 <<>> bonza.rbpllc.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42966 ^^^^^^^^ postconf -d smtp_helo_name smtp_helo_name = $myhostname
So you are using an invalid helo name.
Argh! It's not invalid, it simply does not exist. The matching Postfix check would be to use reject_unknown_helo_hostname. (Very risky, it would reject a lot of desired mails in my case). -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sandy Drobic wrote:
David C. Rankin wrote:
Listmates (Sandy),
I have built a fresh 10.3 server, but smtp performance seems slow. Are there any tips or tricks to improve the mail sending performance. Here
The problem starts here: dig bonza.rbpllc.com
; <<>> DiG 9.4.1-P1 <<>> bonza.rbpllc.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42966 ^^^^^^^^ postconf -d smtp_helo_name smtp_helo_name = $myhostname
So you are using an invalid helo name.
Glad to be with you Sandy! Ok, this one is fixed! root@nemesis:/home/samba/egw3111/backup # dig bonza.rbpllc.com ; <<>> DiG 9.3.2 <<>> bonza.rbpllc.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27035 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;bonza.rbpllc.com. IN A ;; ANSWER SECTION: bonza.rbpllc.com. 2300 IN A 66.76.63.60 ;; AUTHORITY SECTION: rbpllc.com. 4372 IN NS ns1.domaindiscover.com. rbpllc.com. 4372 IN NS ns2.domaindiscover.com. ;; ADDITIONAL SECTION: ns1.domaindiscover.com. 24393 IN A 216.104.162.3 ns2.domaindiscover.com. 47438 IN A 216.104.163.3 ;; Query time: 3 msec ;; SERVER: 192.168.6.16#53(192.168.6.16) ;; WHEN: Wed Jan 9 00:32:34 2008 ;; MSG SIZE rcvd: 133
mynetworks_style = subnet
Better set this manually. If the Server has an official ip address you will invite your neighbor servers to use you as relay.
OK, I'm not sure I understand the response. I have it set, are you telling me I should set it to something else??
smtpd_client_restrictions = check_client_access cidr:/etc/postfix/client_check.cidr, reject_rbl_client relays.ordb.org, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client list.dsbl.org
Several problems: You don't exclude authenticated clients or clients in mynetworks. You are using a dead RBL (relays.ordb.org has gone the way of the dinosaurs).
Ok, I removed relays.ordb.org
Do you use /etc/postfix/access? If not, drop it from your config. In this case it would be a check_sender_access because it is placed in sender_restrictions.
Removed from main.cf
Pet peeve #1: don't use short cuts, always use the complete form. If you decide one day to move the check to smtpd_recipient_restrictions, it would suddenly become a check_recipient_access instead of a check_sender_access.
Better to set up all checks in one class and disable the rest, it's much more transparent that way.
smtpd_client_restrictions = smtpd_sender_restrictions = smtpd_sender_restrictions = smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient permit_mynetworks permit_sasl_authenticated reject_unauth_destination reject_unlisted_recipient # check_client_access hash:/etc/postfix/client_whitelist cidr:/etc/postfix/client_check.cidr check_recipient_access pcre:/etc/postfix/recipient_check.pcre reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, # consider using zen.spamhaus.org! reject_rbl_client sbl-xbl.spamhaus.org reject_rbl_client list.dsbl.org
OK, just using smtpd_recipient_restrictions now.
Pet peeve #2: cidr:/etc/postfix/client_check.cidr check_recipient_access pcre:/etc/postfix/recipient_check.pcre
Can you tell me what kind of checks are in these files? Will you be able to tell me in half a year as well?
Yes, I Blacklist APNIC addresses with client_check.cidr and I Blacklist normally abused accounts (sales, accounting, etc..) with recipient_check.pcre
Let's say, you only use it for blacklisting now, but some day you decide to whitelist someone and say "OK", and suddenly you enable him to use your server as relay, because you might have put the check before reject_unauth_destination. As long as you were only using it to reject clients it wouldn't matter, but whitelist a client and suddenly he can use you as relay. Whitelist a client before you check for valid recipients, and you risk to turn into a backscatter source.
Consider using telling names for the checks:
I see your point, good idea. Thanks.
cidr:/etc/postfix/client_blacklist.cidr pcre:/etc/postfix/recipient_greylisting_enabled.pcre pcre:/etc/postfix/recipient_internal_only.pcre
If necessary split the checks and create separate files for separate purposes (blacklisting/rejecting, whitelisting, filtering etc.), then you can easily place them at the correct place in the order of checks. The policy of your mail system is much more maintainable that way.
smtpd_use_tls = no strict_8bitmime = no strict_rfc821_envelopes = no transport_maps = hash:/etc/postfix/transport unknown_client_reject_code = 550 unknown_local_recipient_reject_code = 550 virtual_alias_domains = hash:/etc/postfix/virtual virtual_alias_maps = hash:/etc/postfix/virtual
Which of these would affect or help smtp response time? Any tips would be appreciated.
After you have fixed your dns settings,
Wow, the mail seems much much faster Sandy! I'll do a little more testing tomorrow. Like I said earlier, good to be with you! -- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (7)
-
Aaron Kulkis -
Carlos E. R. -
Cristian Rodríguez -
David C. Rankin -
Joe Sloan -
Sandy Drobic -
Sloan