Re: 2.10 problem
On Jun 4, 2013, at 10:28 PM, Grant wrote: > I tried switching to the following in main.cf: > > smtpd_relay_restrictions = permit_mynetworks,permit_sasl_auth > > but I started getting messages like this in the log: > > warning: unknown smtpd restriction: "permit_sasl_auth" > 451 4.3.5 Server configuration error permit_sasl_auth <> permit_sasl_authenticated -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
postfix.org != www.postfix.org ?
I keep catching myself typing "postfix.org" and expecting to end up on the Postfix website, and then realizing that I need to put the "www" subdomain on there. Wietse: I'm sure you're aware of how to use mod_rewrite to redirect web traffic from postfix.org to www.postfix.org, but I'm curious as to why you haven't. Is it a mere old-school approach (totally respectable) from when nearly every website had the www prefix, or is there some other reason? Thanks, SteveJ
Re: 2.10 problem
>> am i allowed to ask why disabling smtpd_relay_restrictions only on >> submission? >> & >> is this really the way to use it? ( in master.cf ?) > > This is not good general advice. A properly-configured > smtpd_relay_restrictions should not interfere with submission, and > is not used by pickup (since it's not SMTP). > > The intention of smtpd_relay_restrictions is to be a last-ditch > anti-relay rule to prevent accidents from a misconfigured > smtpd_recipient_restrictions. As such, it should be as bare-bones as > possible, containing ONLY rules related to relaying and not > encumbered with anti-spam or other access rules. > > I expect 99%+ of postfix sites can safely set it to > > # main.cf > smtpd_relay_restrictions = > permit_mynetworks, > # uncomment next line if using SASL > # permit_sasl_authenticated, > reject_unauth_destination > > and leave it at that, with no changes to existing rules. The same > smtpd_relay_restrictions setting should work for > smtp/submission/smtps, so no overrides should be needed in master.cf. > > The only place this won't work correctly is sites doing something > "odd" in smtpd_recipient_restrictions to allow relay from > unauthenticated clients who are not in $mynetworks. > > I've also seen some people suggest that reject_unauth_destination > should be removed from smtpd_recipient_restrictions. I disagree > with that advice too. While technically correct that > reject_unauth_destination is no longer required, there is no general > benefit in removing it except possibly those very few sites with > complex relay rules. I've been running like this: # main.cf smtpd_recipient_restrictions = reject_unauth_destination,permit smtpd_relay_restrictions = # master.cf submission inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_mynetworks,reject_plaintext_session,permit_sasl_authenticated,reject I tried switching to the following in main.cf: smtpd_relay_restrictions = permit_mynetworks,permit_sasl_auth but I started getting messages like this in the log: warning: unknown smtpd restriction: "permit_sasl_auth" 451 4.3.5 Server configuration error - Grant
Re: 2.10 problem
> Grant: >> I recently upgraded from 2.9.5 to 2.10 and ever since I've been having >> an intermittent problem with email sent from within my web framework >> (Interchange - icdevgroup.org) not reaching its recipient. I usually >> get an error message in Interchange's log when there's a postfix >> problem but not with this latest issue. I know this is incredibly >> vague, but can anyone hazard a guess as to what the problem might be? >> >> The big config change I see referenced with regard to 2.10 is >> smtpd_relay_restrictions but I don't see how that could be related. >> My smtpd_relay_restrictions is blank. > > What does Postfix log for a good transaction? > > What does Postfix log for a bad transaction? I upgraded to 2.11 and I'll post back with log info if the problem persists. - Grant
Re: Auth/relaying issues with 2.10.0
Please file a bug report with your distribution. Postfix 2.10 as distributed by me will add a backwards-compatibility setting to main.cf, thusly: # postfix upgrade-configuration COMPATIBILITY: editing /etc/postfix/main.cf, overriding smtpd_relay_restrictions to prevent inbound mail from unexpectedly bouncing. Specify an empty smtpd_relay_restrictions value to keep using smtpd_recipient_restrictions as before. And the backwards compatible setting is: # postconf smtpd_relay_restrictions smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination If your distributor has removed this backwards-compatibility safety net, then please tell them that they are doing their users a disservice. Wietse
Re: Auth/relaying issues with 2.10.0
Hi again, Am Mittwoch, 5. Juni 2013, 01:34:13 schrieb Jan Kohnert: > Am Dienstag, 4. Juni 2013, 18:24:23 schrieb /dev/rob0: > > On Wed, Jun 05, 2013 at 01:08:09AM +0200, Jan Kohnert wrote: > > > I have recently upgraded to 2.10.0 (gentoo) and now having some > > > issues with relaying authenticated users. I'm using dovecot sasl > > > and according to the logs auth works fine, but however postfix > > > thinks I do not want to relay stuff from authenticated users > > > anymore... > > > > Yes. You probably missed the 2.10 release notes. > > > > http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions > > > > smtpd_relay_restrictions = permit_mynetworks, > > > > permit_sasl_authenticated, > > reject_unauth_destination > > That might cause the problem, I really missed that. I'll check that tomorrow > (it's half past one here, now), since a downgrade helped me making a > hotfix… couldn't wait, who needs sleep… :) Things got fixes using your hint. Thanks a lot again! Hint to myself: I should read release notes more carefully. -- MfG Jan
Re: Auth/relaying issues with 2.10.0
Hi, Am Dienstag, 4. Juni 2013, 18:24:23 schrieb /dev/rob0: > On Wed, Jun 05, 2013 at 01:08:09AM +0200, Jan Kohnert wrote: > > I have recently upgraded to 2.10.0 (gentoo) and now having some > > issues with relaying authenticated users. I'm using dovecot sasl > > and according to the logs auth works fine, but however postfix > > thinks I do not want to relay stuff from authenticated users > > anymore... > > Yes. You probably missed the 2.10 release notes. > > http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions > > smtpd_relay_restrictions = permit_mynetworks, > permit_sasl_authenticated, > reject_unauth_destination That might cause the problem, I really missed that. I'll check that tomorrow (it's half past one here, now), since a downgrade helped me making a hotfix… Thanks! -- MfG Jan
Re: Auth/relaying issues with 2.10.0
Hi there again, Am Mittwoch, 5. Juni 2013, 01:08:09 schrieb Jan Kohnert: > I have recently upgraded to 2.10.0 (gentoo) and now having some issues > with relaying authenticated users. I'm using dovecot sasl and according > to the logs auth works fine, but however postfix thinks I do not want to > relay stuff from authenticated users anymore... just downgraded to 2.9.5 (identical config) and it works like a charm: Jun 5 01:19:02 b079 postfix/smtpd[15165]: Anonymous TLS connection established from 178-24-196-94-dynip.superkabel.de[178.24.196.94]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Jun 5 01:19:53 b079 postfix/smtpd[15165]: E6AA4CB9E1: client=178-24-196-94- dynip.superkabel.de[178.24.196.94], sasl_method=plain, sasl_username=jan The last line is never showing up in 2.10.0 (see log in OP). postconf -n alias_maps = hash:/etc/postfix/aliases, hash:/var/lib/mailman/data/aliases allow_min_user = yes command_directory = /usr/sbin config_directory = /etc/postfix content_filter = smtp-amavis:[127.0.0.1]:10024 daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 dovecot_destination_recipient_limit = 1 html_directory = no inet_protocols = all local_destination_concurrency_limit = 2 mail_owner = postfix mail_spool_directory = /var/spool/mail mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 15728600 mime_header_checks = pcre:/etc/postfix/mime_header_checks mydestination = localhost.$mydomain, $mydomain, kohni.$mydomain, claudi. $mydomain, kohni-mobil.$mydomain mydomain = jankoh.mooo.com myhostname = mail.the-pojs.de mynetworks = 127.0.0.0/8 [::1]/128 myorigin = $mydomain newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = no sample_directory = /etc/postfix sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtp_helo_name = the-pojs.de smtp_tls_loglevel = 1 smtp_tls_session_cache_database = btree:/etc/postfix/smtp_scache smtp_tls_session_cache_timeout = 3600s smtp_use_tls = yes smtpd_helo_required = yes smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_multi_recipient_bounce, permit_mynetworks, permit_sasl_authenticated, reject_unlisted_recipient, reject_unauth_destination, reject_unauth_pipelining, reject_invalid_hostname, reject_unknown_sender_domain, reject_rbl_client zen.spamhaus.org, check_policy_service inet:127.0.0.1:10030 smtpd_sasl_auth_enable = yes smtpd_sasl_path = /var/run/dovecot/auth smtpd_sasl_type = dovecot smtpd_sender_login_maps = hash:/etc/postfix/sasl_sender smtpd_sender_restrictions = reject_authenticated_sender_login_mismatch smtpd_tls_CApath = /etc/ssl/certs smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/postfix/cert.pem smtpd_tls_key_file = /etc/postfix/cert.key smtpd_tls_loglevel = 1 smtpd_use_tls = yes soft_bounce = yes unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/virtual virtual_gid_maps = static:500 virtual_mailbox_base = /home/virtualmail virtual_mailbox_domains = the-pojs.dyndns.org, the-pojs.de virtual_mailbox_maps = ldap:/etc/postfix/virtual.cf virtual_minimum_uid = 500 virtual_transport = dovecot virtual_uid_maps = static:102 master for submission: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o content_filter=smtp-amavis:[127.0.0.1]:10026 -o milter_macro_daemon_name=ORIGINATING So either I made a config error, or I found a bug, or the gentoo folks are doing something weird. Any idea? For now I'll stay in 2.9.5… -- MfG Jan
Re: Auth/relaying issues with 2.10.0
On Wed, Jun 05, 2013 at 01:08:09AM +0200, Jan Kohnert wrote: > I have recently upgraded to 2.10.0 (gentoo) and now having some > issues with relaying authenticated users. I'm using dovecot sasl > and according to the logs auth works fine, but however postfix > thinks I do not want to relay stuff from authenticated users > anymore... Yes. You probably missed the 2.10 release notes. http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Auth/relaying issues with 2.10.0
Hi folks, I have recently upgraded to 2.10.0 (gentoo) and now having some issues with relaying authenticated users. I'm using dovecot sasl and according to the logs auth works fine, but however postfix thinks I do not want to relay stuff from authenticated users anymore... Here's the log entry in debug mode: Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: > 178-24-196-94-dynip.superkabel.de[178.24.196.94]: 250-mail.the-pojs.de Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: > 178-24-196-94-dynip.superkabel.de[178.24.196.94]: 250-PIPELINING Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: > 178-24-196-94-dynip.superkabel.de[178.24.196.94]: 250-SIZE 15728600 Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: > 178-24-196-94-dynip.superkabel.de[178.24.196.94]: 250-VRFY Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: > 178-24-196-94-dynip.superkabel.de[178.24.196.94]: 250-ETRN Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: > 178-24-196-94-dynip.superkabel.de[178.24.196.94]: 250-STARTTLS Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: > 178-24-196-94-dynip.superkabel.de[178.24.196.94]: 250-ENHANCEDSTATUSCODES Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: > 178-24-196-94-dynip.superkabel.de[178.24.196.94]: 250-8BITMIME Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: > 178-24-196-94-dynip.superkabel.de[178.24.196.94]: 250 DSN Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: < 178-24-196-94-dynip.superkabel.de[178.24.196.94]: STARTTLS Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: > 178-24-196-94-dynip.superkabel.de[178.24.196.94]: 220 2.0.0 Ready to start TLS Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: send attr request = seed Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: send attr size = 32 Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: private/tlsmgr: wanted attribute: status Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: input attribute name: status Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: input attribute value: 0 Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: private/tlsmgr: wanted attribute: seed Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: input attribute name: seed Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: input attribute value: pIK6HA04uWxAB+svbuTDcRA7kYsqxBKzn+7D798fAzI= Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: private/tlsmgr: wanted attribute: (list terminator) Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: input attribute name: (end) Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: Anonymous TLS connection established from 178-24-196-94-dynip.superkabel.de[178.24.196.94]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: xsasl_dovecot_server_create: SASL service=smtp, realm=(null) Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: name_mask: noanonymous Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: xsasl_dovecot_server_connect: Connecting Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: xsasl_dovecot_server_connect: auth reply: VERSION?1?1 Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: xsasl_dovecot_server_connect: auth reply: MECH?PLAIN?plaintext Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: name_mask: plaintext Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: xsasl_dovecot_server_connect: auth reply: MECH?LOGIN?plaintext Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: name_mask: plaintext Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: xsasl_dovecot_server_connect: auth reply: SPID?30043 Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: xsasl_dovecot_server_connect: auth reply: CUID?2 Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: xsasl_dovecot_server_connect: auth reply: COOKIE?d513800ca06dd779c5f87b04e2a572cd Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: xsasl_dovecot_server_connect: auth reply: DONE Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: xsasl_dovecot_server_mech_filter: keep mechanism: PLAIN Jun 5 00:15:48 b079 postfix/submission/smtpd[30353]: xsasl_dovecot_server_mech_filter: keep mechanism: LOGIN Jun 5 00:15:55 b079 postfix/submission/smtpd[30353]: < 178-24-196-94-dynip.superkabel.de[178.24.196.94]: ehlo mail.the-pojs.de Jun 5 00:15:55 b079 postfix/submission/smtpd[30353]: match_list_match: 178-24-196-94-dynip.superkabel.de: no match Jun 5 00:15:55 b079 postfix/submission/smtpd[30353]: match_list_match: 178.24.196.94: no match Jun 5 00:15:55 b079 postfix/submission/smtpd[30353]: > 178-24-196-94-dynip.superkabel.de[178.24.196.94]: 250-mail.the-pojs.de Jun 5 00:15:55 b079 postfix/submission/smtpd[30353]: > 178-24-196-94-dynip.superkabel.de[178.24.196.94]: 250-PIPELINING Jun 5 00:15:55 b079 postfix/submission/smtpd[30353]: > 178-24-196-94-dynip.superkabel.de[178.24.196.94]: 250-SIZE 15728600 Jun 5 00:15:55 b079 postfix/submis
Re: postdrop permission denied
David Benfell: > Hi, > > All of a sudden, I'm getting a blizzard of these messages in my logs: > > postfix/postdrop[23453]: warning: mail_queue_enter: create file > maildrop/558196.23453: Permission denied Someone removed the set-gid bits from /usr/sbin/postdrop and /usr/sbin/postqueue? Execute as root: postfix set-permissions Then go find out who messed up the system. Wietse > Some mail seems to not be making it through. I haven't touched the > configuration in a few weeks. The only significant system > configuration change has been an Arch Linux upgrade that consolidated > executables from /sbin, /bin, and /usr/sbin into /usr/bin > > Help! > > Thanks! > -- > David Benfell / benf...@parts-unknown.org > Please see https://parts-unknown.org/node/2 for GnuPG information (or > the attachment you don't understand) -- End of PGP signed section, PGP failed!
Re: monitoring with Icinga?
On 04 Jun 2013, at 10:27 , Robert L Mathews wrote: > "In general, the thing I've learned about monitoring is that when possible, > check the system by using it, rather [than] looking for changes in side > effects (such as logs, or number of processes running, etc.). That's not to > say that the other things can't give useful information, too, but if you can > check the system by using it, you don't have to worry so much about whether > you've added a regexp for every possible log entry and so forth." Great advice. I will simply add that what I use as my first-line monitor is the free MX monitoring that mxtoolbox.com offers, as well as an uptime monitor from uptimerobot.com I'm not affiliated with either service other than using them to monitor my connectivity. The only down side to uptime robot is that it checks every five minutes, and that may not be fast enough for some people. For me, checking the SMTP server and the WWW servers every 5 minutes works out pretty well. YMMV. -- My mind is going. There is no question about it. I can feel it. I can feel it. I can feel it. I'm... afraid.
postdrop permission denied
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, All of a sudden, I'm getting a blizzard of these messages in my logs: postfix/postdrop[23453]: warning: mail_queue_enter: create file maildrop/558196.23453: Permission denied Some mail seems to not be making it through. I haven't touched the configuration in a few weeks. The only significant system configuration change has been an Arch Linux upgrade that consolidated executables from /sbin, /bin, and /usr/sbin into /usr/bin Help! Thanks! - -- David Benfell / benf...@parts-unknown.org Please see https://parts-unknown.org/node/2 for GnuPG information (or the attachment you don't understand) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRrkcBAAoJELJhbl/uPb4SgKMP/jTSgo/NxtLZA6flxbElIwMD I2FyPg3yXKwgOUl+3PQFPYHn9QTM0Oyir1udwhc7kApDbwf9vW192Mmf68AVziIr Y+CZbvczxnEqYXZneJBbRCSDWw8/YPyPURkkUbn6x7n9Otkyyo3euMyurC34++FZ VvNKIA4f3XfMihNlPaHPqHt0WzQ6mJW8q0n8vFRu2QO56Uha2B+kIoHvFksHO1d/ iGozZ01esWpQHxhUbxRDMIc23JQv9XYXKMJxT04ZIxBD8zQAiTXVsjseMfUZPlMz HgIDJGz6scM3i3+ba0Ua6CgnAqAHENnAZtzNd/LrMoEPVzy02sLUBGuZAPHoTerb YR9Z450sfsRMMjO7qj/Dn3tDdx0Dz4tSy3rxJlJkeANEHf//MpocHuXq7s0zW6JQ srd5rRmU3TOoeaMKmuqSapVF/cUoGs4arVkXvsl50fZvXXblMZ2JgYYtzA/isk2M TLhZkYI/Bx8RZgMcQaHPziBbOsU9Xjrc6kNK0gbXybJhULV3Jg3fdBSbtQJEvF0F JzD5P/27kfehWxodNVzYQgawe3mhpHMkF3i9sBzb9ls8SQq6Fc/IWRPUp9EZ8Lxl kDEyB01sOWSlaahArpwFLxCVj75eiWR205RfyOW2jtivy0pdUBvzka56ok49p5hE unxLFkBchqJBKaM6SPce =h4RM -END PGP SIGNATURE-
Re: Relay attempts from bot filling mail queue and getting my server blacklisted: how's it happening?
b...@indietorrent.org: > For the sake of thoroughness, and because I'm expected to perform a > root-cause-analysis, I'm following-up on this after noticing that there was > a missing comma in the smtpd_recipient_restrictions directive (after > check_recipient_access on the third line): > > smtpd_recipient_restrictions = > permit_mynetworks, > permit_sasl_authenticated, For posteriority (i.e. people who find this with a search engine), replace these three lines: > check_recipient_access > mysql:/etc/postfix/mysql-virtual_recipient.cf, > reject_unauth_destination, with these three lines: > reject_unauth_destination, > check_recipient_access > mysql:/etc/postfix/mysql-virtual_recipient.cf, As that prevents unexpected open relay problems. > reject_invalid_hostname, > reject_non_fqdn_hostname, > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_unknown_sender_domain, > reject_unknown_recipient_domain, > reject_unauth_destination, > reject_rbl_client bl.spamcop.net, > reject_rbl_client zen.spamhaus.org > > Even though the problem seems to be resolved after adding the comma and > swapping the two items as Wietse suggested, what would be the net-result of > the missing comma in my version of Postfix (2.7.0)? Would the entire list > of smtpd_recipient_restrictions be ignored? (That would certainly explain > why a bot was able to relay hundreds of thousands of messages the course of > a few days.) The comma is treated here as whitespace. Wietse
Re: Relay attempts from bot filling mail queue and getting my server blacklisted: how's it happening?
On Tue, Jun 04, 2013 at 12:25:16PM -0700, b...@indietorrent.org wrote: > For the sake of thoroughness, and because I'm expected to perform a > root-cause-analysis, I'm following-up on this after noticing that there was > a missing comma in the smtpd_recipient_restrictions directive (after > check_recipient_access on the third line): > > smtpd_recipient_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > check_recipient_access > mysql:/etc/postfix/mysql-virtual_recipient.cf, > reject_unauth_destination, > reject_invalid_hostname, > reject_non_fqdn_hostname, > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_unknown_sender_domain, > reject_unknown_recipient_domain, > reject_unauth_destination, > reject_rbl_client bl.spamcop.net, > reject_rbl_client zen.spamhaus.org Postfix does not distinguish between commas and whitespace in this context. You can remove them all if you please. They make the rules more *human-readable*, by placing commas between complete rule elements, rather than individual tokens. So I would write your rules as: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_destination, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org for clarity, but it makes no difference. -- Viktor.
Re: Relay attempts from bot filling mail queue and getting my server blacklisted: how's it happening?
On Wed, 29 May 2013 10:34:37 -0400, Ben Johnson wrote: > On 5/28/2013 1:38 PM, Wietse Venema wrote: >> Viktor Dukhovni: >>> On Tue, May 28, 2013 at 01:18:25PM -0400, Wietse Venema wrote: >>> I strongly suggest that you swap the order of the following two rules in main.cf: check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf, reject_unauth_destination, This should be: reject_unauth_destination, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf, Many open relay problems are caused by having an access table before reject_unauth_destination. >>> >>> Indeed the second form is safer, and equivalent provided all the >>> recipients are in a domain that is not rejected by >>> reject_unauth_destination. >>> >>> Though in this case it is a *recipient* check, so problems are unlikely, >>> unless the table includes unintended remote addresses. Unlike sender >>> addresses, recipient addresses are not subject to "forgery". >> >> There is no need to forge "u...@yahoo.com" if a spammer really >> wants to send mail there :-) >> >> Wietse >> > > Thanks, Wietse. > > Regarding your first reply, I've reviewed the information at > http://www.postfix.org/DEBUG_README.html#mail and will do my best to > adhere to protocol going forward. (That was my first post; sincere > apologies.) > > I have re-ordered those two rules and will post back if that doesn't > solve the problem. I really appreciate your time and assistance. > > Best regards, > > -Ben For the sake of thoroughness, and because I'm expected to perform a root-cause-analysis, I'm following-up on this after noticing that there was a missing comma in the smtpd_recipient_restrictions directive (after check_recipient_access on the third line): smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_destination, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org Even though the problem seems to be resolved after adding the comma and swapping the two items as Wietse suggested, what would be the net-result of the missing comma in my version of Postfix (2.7.0)? Would the entire list of smtpd_recipient_restrictions be ignored? (That would certainly explain why a bot was able to relay hundreds of thousands of messages the course of a few days.) Thank you! -Ben
Re: 2.10 problem
On 6/4/2013 10:34 AM, Marko Weber | ZBF wrote: > > > Am 2013-06-04 15:00, schrieb Benny Pedersen: >> Grant skrev den 2013-06-04 01:45: >> >>> The big config change I see referenced with regard to 2.10 is >>> smtpd_relay_restrictions but I don't see how that could be related. >>> My smtpd_relay_restrictions is blank. >> >> suggest to make it not in main.cf, but use this restriction only on >> master.cf to disable it for submission and pickup service ports so >> its >> just add -o smtpd_relay_restrictions= on this lines in master.cf >> >> it worked for me :) > > am i allowed to ask why disabling smtpd_relay_restrictions only on > submission? > & > is this really the way to use it? ( in master.cf ?) This is not good general advice. A properly-configured smtpd_relay_restrictions should not interfere with submission, and is not used by pickup (since it's not SMTP). The intention of smtpd_relay_restrictions is to be a last-ditch anti-relay rule to prevent accidents from a misconfigured smtpd_recipient_restrictions. As such, it should be as bare-bones as possible, containing ONLY rules related to relaying and not encumbered with anti-spam or other access rules. I expect 99%+ of postfix sites can safely set it to # main.cf smtpd_relay_restrictions = permit_mynetworks, # uncomment next line if using SASL # permit_sasl_authenticated, reject_unauth_destination and leave it at that, with no changes to existing rules. The same smtpd_relay_restrictions setting should work for smtp/submission/smtps, so no overrides should be needed in master.cf. The only place this won't work correctly is sites doing something "odd" in smtpd_recipient_restrictions to allow relay from unauthenticated clients who are not in $mynetworks. I've also seen some people suggest that reject_unauth_destination should be removed from smtpd_recipient_restrictions. I disagree with that advice too. While technically correct that reject_unauth_destination is no longer required, there is no general benefit in removing it except possibly those very few sites with complex relay rules. -- Noel Jones
Re: monitoring with Icinga?
On 6/2/13 9:12 AM, Wietse Venema wrote: > For example, periodically send email to mailboxname+timest...@example.com, > and parse the "to=" and > "status=delivered" out of the logfile record stream. Or, even better, try to retrieve those messages from the actual mailbox using POP3. That way you've simulated everything a user does, end to end. This is not hard to do. Using the Perl modules Net::SMTP and Net::POP3, it's easy to write a Nagios/Icinga check that operates thusly: 1. Using POP3, check for a message with a timestamp in the subject that indicates that it was sent in the last X minutes (where X is the maximum delay you're willing to tolerate). If not found, the result will be CRITICAL. 2. Using POP3, delete every message in the mailbox. 3. Using SMTP, send a new message to the mailbox with a timestamp in the subject. That's all it takes. Each time the check runs, (1) should find the message sent by (3) of the previous check. The "timestamp in the subject" can be as simple as the epoch seconds. As I wrote on this list 11 years ago(!), "In general, the thing I've learned about monitoring is that when possible, check the system by using it, rather [than] looking for changes in side effects (such as logs, or number of processes running, etc.). That's not to say that the other things can't give useful information, too, but if you can check the system by using it, you don't have to worry so much about whether you've added a regexp for every possible log entry and so forth." -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/
Re: 2.10 problem
Marko Weber | ZBF skrev den 2013-06-04 17:34: am i allowed to ask why disabling smtpd_relay_restrictions only on submission? submission users is here sasl auth users, if sasl is not enforced then it will be in error to remove relay restrictions, if you ensure smtp auth its perfectly ok is this really the way to use it? ( in master.cf ?) depending of logs yes -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: 2.10 problem
Am 2013-06-04 15:00, schrieb Benny Pedersen: Grant skrev den 2013-06-04 01:45: The big config change I see referenced with regard to 2.10 is smtpd_relay_restrictions but I don't see how that could be related. My smtpd_relay_restrictions is blank. suggest to make it not in main.cf, but use this restriction only on master.cf to disable it for submission and pickup service ports so its just add -o smtpd_relay_restrictions= on this lines in master.cf it worked for me :) am i allowed to ask why disabling smtpd_relay_restrictions only on submission? & is this really the way to use it? ( in master.cf ?)
Re: 2.10 problem
Jerry skrev den 2013-06-04 12:09: Someone has way too much time on their hands! and others still not understanding configure postfix 2.10 yet :) -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: 2.10 problem
Grant skrev den 2013-06-04 01:45: The big config change I see referenced with regard to 2.10 is smtpd_relay_restrictions but I don't see how that could be related. My smtpd_relay_restrictions is blank. suggest to make it not in main.cf, but use this restriction only on master.cf to disable it for submission and pickup service ports so its just add -o smtpd_relay_restrictions= on this lines in master.cf it worked for me :) -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: question about postfix queue scheduler
On Tue, Jun 04, 2013 at 01:44:46PM CEST, Tom Hendrikx said: > On 06/04/2013 01:22 PM, Antonio Gutiérrez Mayoral wrote: > > Hi Wietse, > > > > Yes, its a solution, but these emails should be delivered in > > bussines-time :-( > > (it doesnt matter if it takes 2 hours... but in bussiness time...) > > > > thank you so much! > > > > You could run a script as a cronjob that queues x messages when the > active queue contains (100 minus x) messages (where 100 is an arbitrary > number). This means that all mails on HOLD trickle out as quick as > possible, while not overloading the active queue... It means when the queue has 100 messages, you stop sending anything ?
Re: 2.10 problem
not much required, 'man 6 figlet' On Tue, Jun 4, 2013 at 7:09 AM, Jerry wrote: > On Tue, 4 Jun 2013 00:08:17 + > Viktor Dukhovni articulated: > > > On Mon, Jun 03, 2013 at 04:45:41PM -0700, Grant wrote: > > > > > I know this is incredibly vague, but can anyone hazard a guess as to > > > what the problem might be? > > > > L O G S > > L 0 0 G G S > > L 0 0 G GG S > > L 0 0 G S > > L 0 0 G S > > L 0 0 G S > > L 0 0 G G S > > L O G S > > Someone has way too much time on their hands! > > -- > Jerry ✌ > postfix-u...@seibercom.net > _ > TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail > TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html > >
Re: question about postfix queue scheduler
On 06/04/2013 01:22 PM, Antonio Gutiérrez Mayoral wrote: > Hi Wietse, > > Yes, its a solution, but these emails should be delivered in > bussines-time :-( > (it doesnt matter if it takes 2 hours... but in bussiness time...) > > thank you so much! > You could run a script as a cronjob that queues x messages when the active queue contains (100 minus x) messages (where 100 is an arbitrary number). This means that all mails on HOLD trickle out as quick as possible, while not overloading the active queue... -- Tom
Re: question about postfix queue scheduler
Hi Wietse, Yes, its a solution, but these emails should be delivered in bussines-time :-( (it doesnt matter if it takes 2 hours... but in bussiness time...) thank you so much! 2013/6/4 Wietse Venema > Maybe you can automatically HOLD all his mail and then automatically > release all his mail in the evening. > > Wietse > -- -- Antonio Gutiérrez Mayoral
Re: question about postfix queue scheduler
* Wietse Venema : > Maybe you can automatically HOLD all his mail and then automatically > release all his mail in the evening. I even have a script for that... -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: question about postfix queue scheduler
Maybe you can automatically HOLD all his mail and then automatically release all his mail in the evening. Wietse
question about postfix queue scheduler
Hi all! My name is Antonio I am currently managing a system with postfix+ spamassassin and Maia. First of all, sorry for my bad english. I would like to ask a question. Once in a month, more or less, I have a user who sends a LOT of mails (mailing) to a group of recipients. This list could have about 2000 recipients. The email has two pdfs, maybe 2 MB per email. When this user sends this email, maybe the queue hold about 2000 requests, today about 300 MB. The problem is that the queue starts to deliver the email and the other email which sends the other users, is not being processed until ALL the emails for this user has been processed (FIFO queue) So, the only way I have to deal with is HOLD all messages for this user, with postsuper -h and requeue them step by step, maybe 100 emails per 5 minutes. I dont know if there is a way for improve this. The main problem is the email can not be stopped, the emails have to in/out normally. And, I cannot say to this user that I cant send this emails... :-) Maybe the only solution is install another smtp or an marketing-email app ? Any suggestions? Thanks! -- -- Antonio Gutiérrez Mayoral
Re: 2.10 problem
On Tue, 4 Jun 2013 00:08:17 + Viktor Dukhovni articulated: > On Mon, Jun 03, 2013 at 04:45:41PM -0700, Grant wrote: > > > I know this is incredibly vague, but can anyone hazard a guess as to > > what the problem might be? > > L O G S > L 0 0 G G S > L 0 0 G GG S > L 0 0 G S > L 0 0 G S > L 0 0 G S > L 0 0 G G S > L O G S Someone has way too much time on their hands! -- Jerry ✌ postfix-u...@seibercom.net _ TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html
