"ideal" postscreen config (was: Re: postscreen MX Policy ...)
On Sun, Jun 05, 2011 at 08:24:40PM +0530, kshitij mali wrote: > Since till now i was using postfix 2.5 i am planning to upgrade to > 2.8 because i see 2 major feature multi -instance and postscreen > can any one give me with example of an ideal conguration . 2.8 is a very good idea. I can highly recommend the upgrade. I am in the late stages of preparing a presentation for the SELF conference next weekend[1] which will discuss what I have done with mine, and the results I am getting. In fact the log-watching which prompted this thread was part of my research. (Aside: it is rather daunting to be indirectly following up on Wietse's presentation at SELF 2010. But mine has different aims: to discuss implementation details and results, rather than the design and theory. Moreover, it means I get to spend a fun weekend with friends and fellow geeks. :) ) I have to point out that there is no such thing as "ideal" for all sites, and also that multi-instance and postscreen are unrelated features, except insofar as postscreen is global (at least per IP listening address; you might choose multiple instances if you must maintain different postscreen settings per recipient domain, for example.) I'm not yet finished with the preparation, but it will be made available online after the SELF event. In the meantime, what was posted in this thread is a configuration which makes use of all postscreen features to some extent, and it is very successful in practice at my small and atypical site. (Every Internet site is atypical, for that matter.) In February I posted some about what postscreen was doing for me: http://permalink.gmane.org/gmane.mail.postfix.user/218114 In the future I might add some more aggressive DNSBLs scored as one-point sites. Only you can decide what lists you are willing to trust, and to what extent, so I do not recommend copy/paste of my postscreen settings. Also see the offcial documentation, to which I am making frequent reference: http://www.postfix.org/POSTSCREEN_README.html and the corresponding document for multiple instance management: http://www.postfix.org/MULTI_INSTANCE_README.html [1] http://www.southeastlinuxfest.org/ 2011-06-10 through -12, Spartanburg, South Carolina USA. If anyone on the list is planning to attend, please say hello when we're there, and I hope the presentation is of interest. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: postscreen MX Policy test and multiple listening IP addresses
On Sun, Jun 05, 2011 at 10:21:38AM -0400, Wietse Venema wrote: > /dev/rob0: > > Jun 5 01:50:46 cardinal postfix/postscreen[15628]: CONNECT from > > [174.37.3.121]:33695 to [216.23.247.74]:25 > > Jun 5 01:50:52 cardinal postfix/postscreen[15628]: PASS OLD > > [174.37.3.121]:33695 > > Jun 5 01:50:52 cardinal postfix/smtpd[15816]: connect from > > 174.37.3.121-static.reverse.softlayer.com[174.37.3.121] > > Host connects 01:50:46, postscreen logs "PASS OLD" at 01:50:52 and > hands off the connection to smtpd. The six-second pause suggests > that postscreen_greet_ttl (1d) expired (according to "postconf -n" > your postscreen_mumble_ttl settings haven't changed). Given the cron job flush finding in my previous post on this thread, it's making sense why these TTL settings are expiring at around the same time, and even between primary/secondary attempts. To partly hijack my own thread (with a wink and a nod to my friend and colleague Jeroen), I'd like to stop this. The sender domain, which in the OP was not munged, is NXDOMAIN: rob0@cardinal:~$ host -tany forums.playdom.com. Host forums.playdom.com. not found: 3(NXDOMAIN) Lacking what I would call a "complete" understanding of RFC 5321 and predecessors, I have never tried setting unknown_address_reject_code to 550. Having seen this post from Viktor: http://permalink.gmane.org/gmane.mail.postfix.user/133564 I did that, and then turned this one away: Jun 5 21:54:03 cardinal postfix/postscreen[3582]: CONNECT from [174.37.3.121]:35549 to [216.23.247.74]:25 Jun 5 21:54:03 cardinal postfix/postscreen[3582]: PASS OLD [174.37.3.121]:35549 Jun 5 21:54:03 cardinal postfix/smtpd[3808]: connect from 174.37.3.121-static.reverse.softlayer.com[174.37.3.121] Jun 5 21:54:03 cardinal postfix/smtpd[3808]: setting up TLS connection from 174.37.3.121-static.reverse.softlayer.com[174.37.3.121] Jun 5 21:54:04 cardinal postfix/smtpd[3808]: Anonymous TLS connection established from 174.37.3.121-static.reverse.softlayer.com[174.37.3.121]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Jun 5 21:54:04 cardinal postfix/smtpd[3808]: NOQUEUE: reject: RCPT from 174.37.3.121-static.reverse.softlayer.com[174.37.3.121]: 550 5.1.8 : Sender address rejected: Domain not found; from= to= proto=ESMTP helo= Jun 5 21:54:04 cardinal postfix/smtpd[3808]: disconnect from 174.37.3.121-static.reverse.softlayer.com[174.37.3.121] And there was no followup on [216.23.247.78]:25. Looking again just now, I see no further attempts. Good riddance! I'll take the opportunity at this point to suggest softening the postconf.5.html#unknown_address_reject_code warning: "Do not change this unless you have a complete understanding of RFC 2821." There's nothing wrong, and it seems to me, a lot *right*, about rejecting NXDOMAIN addresses with 550. > > Jun 5 01:50:53 cardinal postfix/postscreen[15628]: CONNECT from > > [174.37.3.121]:52927 to [216.23.247.78]:25 > > Jun 5 01:50:53 cardinal postfix/postscreen[15628]: WHITELIST VETO > > [174.37.3.121]:52927 > > > It was whitelisted 7 seconds ago. Could that have expired? > > What 7 seconds? the "PASS OLD" action was logged 01:50:52. The > new connection is made 01:50:53. > > Each postscreen test has its own TTL. Different tests have different > costs (for sender and receiver), and therefore different tests > expire at different times. > > You have the following time-dependent tests enabled: > > postscreen_bare_newline_action = enforce > postscreen_dnsbl_action = enforce > postscreen_greet_action = enforce > > Their expiration times are: > > postscreen_bare_newline_ttl = 30d > postscreen_dnsbl_ttl = 1h > postscreen_greet_ttl = 1d > > Clearly, they don't expire at the same time. Right, I understood this, but had never thought about how the staggered expirations interact with one another. Since the postscreen_cache_map is shared for all tests, I guess that means "PASS NEW" is logged only if the client is not in the map at all. > The Postfix verify(8) daemon avoids client-visible delays by sending > a new probe before a result expires (it has separate _refresh and > _expire timing parameters). > > That trick does not work with postscreen. postscreen does not have > separate _refresh and _expire settings because many postscreen > tests are client-visible. For example, postscreen_greet is visible > (6 seconds delay), postscreen_dnsbl almost invisible (less than 1 > second, usually) and postscreen_bare_newline means the client gets > 4XX replies if it passes the test. So, in the majority of tests it > is not possible to refresh a test without client-visible delays. In this case it looks like we had an expired postscreen_greet_ttl for the first (primary MX) attempt, and an expired postscreen_dnsbl_ttl for the second (WHITELIST VETO) attempt. Interesting. > When a test has expired, postscreen could refresh all unexpired > tests that will expire soon. For example, all tests that will > ex
Re: Postfix/Sendmail and Apache James
On 06/06/2011 01:11 AM, Jeroen Geilman wrote: On 06/06/2011 01:02 AM, Marc Chamberlin wrote: Thanks Wietse for replying! From your reply, I think you are interpreting my question as asking how Apache James can use Postfix/Sendmail to process email for it. Actually, what I need is the other way around, how to configure Postfix/Sendmail to relay email to the Apache James email server without causing a conflict between the two services. If you follow the link to the webpage that I provided in my posting, it will explain what is needed to run the old Sendmail app with Apache James. Basically there are 4 things which need to be done - 1. Stop Postfix/Sendmail from running as an SMTP daemon 2. Set up Postfix's frontend Sendmail to relay email to the James server on localhost. 3. Stop Postfix's Sendmail complaining about mail apparently looping back, if necessary. 4. James requires SMTP AUTH, so mail relayed to it from Sendmail will need to follow the log in protocols. I won't need Postfix to receive and process email for local users either, just need the Sendmail API for other applications running on the servers. 1. Comment out the smtpd(8) service in master.cf. 2. Configure the domains in question as relay_domains; fill in relay_recipient_maps if they are known, or unset it if they are not. NOTE that unsetting relay_recipient_maps inherently trusts all mail submitted via sendmail(1); it's up to you if you want to risk this. I forgot to mention that if you want to allow this for ALL mail, this won't work; you will have to allow all mail to relay through postfix, and set up relayhost to point to your James instance. The risk noted above will increase accordingly. 3. Show that this happens at all. 4. Set up client SASL in the smtp(8) service as documented in http://www.postfix.org/SASL_README.html#client_sasl Reload postfix. -- J.
Re: Postfix/Sendmail and Apache James
On 06/06/2011 01:02 AM, Marc Chamberlin wrote: Thanks Wietse for replying! From your reply, I think you are interpreting my question as asking how Apache James can use Postfix/Sendmail to process email for it. Actually, what I need is the other way around, how to configure Postfix/Sendmail to relay email to the Apache James email server without causing a conflict between the two services. If you follow the link to the webpage that I provided in my posting, it will explain what is needed to run the old Sendmail app with Apache James. Basically there are 4 things which need to be done - 1. Stop Postfix/Sendmail from running as an SMTP daemon 2. Set up Postfix's frontend Sendmail to relay email to the James server on localhost. 3. Stop Postfix's Sendmail complaining about mail apparently looping back, if necessary. 4. James requires SMTP AUTH, so mail relayed to it from Sendmail will need to follow the log in protocols. I won't need Postfix to receive and process email for local users either, just need the Sendmail API for other applications running on the servers. 1. Comment out the smtpd(8) service in master.cf. 2. Configure the domains in question as relay_domains; fill in relay_recipient_maps if they are known, or unset it if they are not. NOTE that unsetting relay_recipient_maps inherently trusts all mail submitted via sendmail(1); it's up to you if you want to risk this. 3. Show that this happens at all. 4. Set up client SASL in the smtp(8) service as documented in http://www.postfix.org/SASL_README.html#client_sasl Reload postfix. -- J.
Re: Postfix/Sendmail and Apache James
On 6/5/2011 9:36 AM, Wietse Venema wrote: > Marc Chamberlin: >> Hello - >> >> I am a new subscriber to this mail list and am in need of some help >> configuring Postfix/Sendmail to work with the Apache James email server. >> Don't get me wrong on this, Postfix is probably a fine MTA, but I have >> some complex mailets designed which run under Apache James. ;-) Anywise, >> in the past, I have usually turned off Postfix, on my servers, and just >> used the older Sendmail to handle the mail interface for some other >> applications that are also running on my servers. (Bugzilla and Bacula >> in particular) To accomplish this, the people at Apache James supplied a >> set of instructions (now found at >> http://wiki.apache.org/james/JamesAndSendmail ) to configure Sendmail >> just to relay email it picks up, to James, and not conflict with James >> in using the ports) >> >> My distro (openSuSE 11.4) appears to be dropping the older Sendmail and >> moving towards Postfix instead. I know that Postfix supplies a somewhat >> compatible SendMail front end, so as to remain compatible with those >> applications that use Sendmail. What I need to know is how to configure >> Postfix/SendMail to work with and be compatible with Apache James. In >> other words, I would like to be able to accomplish the same effective >> configuration as was done and explained on the above mentioned webpage. > If you can describe what Sendmail features Apache James requires, > then an experienced Postix admin here can tell you if you need to > change any Apache/Postfix settings at all. > > For example, if it connected to Sendmail with SMTP, then all settings > you need are in http://www.postfix.org/BASIC_CONFIGURATION_README.html. > > Wietse > Thanks Wietse for replying! From your reply, I think you are interpreting my question as asking how Apache James can use Postfix/Sendmail to process email for it. Actually, what I need is the other way around, how to configure Postfix/Sendmail to relay email to the Apache James email server without causing a conflict between the two services. If you follow the link to the webpage that I provided in my posting, it will explain what is needed to run the old Sendmail app with Apache James. Basically there are 4 things which need to be done - 1. Stop Postfix/Sendmail from running as an SMTP daemon 2. Set up Postfix's frontend Sendmail to relay email to the James server on localhost. 3. Stop Postfix's Sendmail complaining about mail apparently looping back, if necessary. 4. James requires SMTP AUTH, so mail relayed to it from Sendmail will need to follow the log in protocols. I won't need Postfix to receive and process email for local users either, just need the Sendmail API for other applications running on the servers. Marc Chamberlin
Re: fatal: lock file defer error
Nikolaos Milas: > On 23/5/2011 9:26 ??, Nikolaos Milas wrote: > > > With some googling I found this rather old message: > > http://archives.neohapsis.com/archives/postfix/2004-03/2663.html where > > Wietse suggested to increase the var_flock_tries undocumented > > parameter in main.cf (from 20 to 40). > > > > Would this suggestion be applicable in the case too? > > > > > > Although no one has responded on this, I would like to mention that I > have not seen this error again for more than a week, since I upgraded to > latest version (2.8.3) - built from source. > > I can't tell if it's a coincidence, but things seem to be running > smoothly now. FYI, the code around that error message has not changed since it was put there in 2000. Also FYI, virtual machine monitors have problems with accurately delivering timer interrupts when they manage many virtual guests (or virtual CPUs). Virtual machine monitors play with the guest's clock to compensate. This makes Postfix's time-based defenses less effective than they could be, because time is not smooth as it should be. A while ago, someone tried to run Postfix on eight virtual CPUs on ESX. Postfix would randomly hang until they went down to two virtual CPUs. That's not a bug in Postfix. It's incomplete virtual hardware emulation that loses timer events that Postfix relies on. Wietse
Re: fatal: lock file defer error
On 23/5/2011 9:26 πμ, Nikolaos Milas wrote: With some googling I found this rather old message: http://archives.neohapsis.com/archives/postfix/2004-03/2663.html where Wietse suggested to increase the var_flock_tries undocumented parameter in main.cf (from 20 to 40). Would this suggestion be applicable in the case too? Although no one has responded on this, I would like to mention that I have not seen this error again for more than a week, since I upgraded to latest version (2.8.3) - built from source. I can't tell if it's a coincidence, but things seem to be running smoothly now. Regards, Nick smime.p7s Description: S/MIME Cryptographic Signature
Re: Postfix/Sendmail and Apache James
Marc Chamberlin: > Hello - > > I am a new subscriber to this mail list and am in need of some help > configuring Postfix/Sendmail to work with the Apache James email server. > Don't get me wrong on this, Postfix is probably a fine MTA, but I have > some complex mailets designed which run under Apache James. ;-) Anywise, > in the past, I have usually turned off Postfix, on my servers, and just > used the older Sendmail to handle the mail interface for some other > applications that are also running on my servers. (Bugzilla and Bacula > in particular) To accomplish this, the people at Apache James supplied a > set of instructions (now found at > http://wiki.apache.org/james/JamesAndSendmail ) to configure Sendmail > just to relay email it picks up, to James, and not conflict with James > in using the ports) > > My distro (openSuSE 11.4) appears to be dropping the older Sendmail and > moving towards Postfix instead. I know that Postfix supplies a somewhat > compatible SendMail front end, so as to remain compatible with those > applications that use Sendmail. What I need to know is how to configure > Postfix/SendMail to work with and be compatible with Apache James. In > other words, I would like to be able to accomplish the same effective > configuration as was done and explained on the above mentioned webpage. If you can describe what Sendmail features Apache James requires, then an experienced Postix admin here can tell you if you need to change any Apache/Postfix settings at all. For example, if it connected to Sendmail with SMTP, then all settings you need are in http://www.postfix.org/BASIC_CONFIGURATION_README.html. Wietse
Re: postscreen MX Policy test and multiple listening IP addresses
On 06/05/2011 04:54 PM, kshitij mali wrote: Hello all, HI! Please: 1. DO NOT Top-post, 2. Reply to the LIST, and 3. DO NOT hijack threads for your own issues. Thanks! -- J.
Postfix/Sendmail and Apache James
Hello - I am a new subscriber to this mail list and am in need of some help configuring Postfix/Sendmail to work with the Apache James email server. Don't get me wrong on this, Postfix is probably a fine MTA, but I have some complex mailets designed which run under Apache James. ;-) Anywise, in the past, I have usually turned off Postfix, on my servers, and just used the older Sendmail to handle the mail interface for some other applications that are also running on my servers. (Bugzilla and Bacula in particular) To accomplish this, the people at Apache James supplied a set of instructions (now found at http://wiki.apache.org/james/JamesAndSendmail ) to configure Sendmail just to relay email it picks up, to James, and not conflict with James in using the ports) My distro (openSuSE 11.4) appears to be dropping the older Sendmail and moving towards Postfix instead. I know that Postfix supplies a somewhat compatible SendMail front end, so as to remain compatible with those applications that use Sendmail. What I need to know is how to configure Postfix/SendMail to work with and be compatible with Apache James. In other words, I would like to be able to accomplish the same effective configuration as was done and explained on the above mentioned webpage. Would some kind Postfix guru be willing to help me with this? Sure would appreciate it, and I will help/work with the James webmaster to update their wiki so the Postfix mail list won't be bothered with others asking this same question. Many thanks in advance! Marc Chamberlin
Re: postscreen MX Policy test and multiple listening IP addresses
Hello all, Since till now i was using postfix 2.5 i am planning to upgrade to 2.8 because i see 2 major feature multi -instance and postscreen can any one give me with example of an ideal conguration . Regards, Kshitij On Sun, Jun 5, 2011 at 7:51 PM, Wietse Venema wrote: > /dev/rob0: > > Jun 5 01:50:46 cardinal postfix/postscreen[15628]: CONNECT from > > [174.37.3.121]:33695 to [216.23.247.74]:25 > > Jun 5 01:50:52 cardinal postfix/postscreen[15628]: PASS OLD > > [174.37.3.121]:33695 > > Jun 5 01:50:52 cardinal postfix/smtpd[15816]: connect from > > 174.37.3.121-static.reverse.softlayer.com[174.37.3.121] > > Host connects 01:50:46, postscreen logs "PASS OLD" at 01:50:52 and > hands off the connection to smtpd. The six-second pause suggests > that postscreen_greet_ttl (1d) expired (according to "postconf -n" > your postscreen_mumble_ttl settings haven't changed). > > > Jun 5 01:50:53 cardinal postfix/postscreen[15628]: CONNECT from > > [174.37.3.121]:52927 to [216.23.247.78]:25 > > Jun 5 01:50:53 cardinal postfix/postscreen[15628]: WHITELIST VETO > > [174.37.3.121]:52927 > > > It was whitelisted 7 seconds ago. Could that have expired? > > What 7 seconds? the "PASS OLD" action was logged 01:50:52. The > new connection is made 01:50:53. > > Each postscreen test has its own TTL. Different tests have different > costs (for sender and receiver), and therefore different tests > expire at different times. > > You have the following time-dependent tests enabled: > >postscreen_bare_newline_action = enforce >postscreen_dnsbl_action = enforce >postscreen_greet_action = enforce > > Their expiration times are: > >postscreen_bare_newline_ttl = 30d >postscreen_dnsbl_ttl = 1h >postscreen_greet_ttl = 1d > > Clearly, they don't expire at the same time. > > The Postfix verify(8) daemon avoids client-visible delays by sending > a new probe before a result expires (it has separate _refresh and > _expire timing parameters). > > That trick does not work with postscreen. postscreen does not have > separate _refresh and _expire settings because many postscreen > tests are client-visible. For example, postscreen_greet is visible > (6 seconds delay), postscreen_dnsbl almost invisible (less than 1 > second, usually) and postscreen_bare_newline means the client gets > 4XX replies if it passes the test. So, in the majority of tests it > is not possible to refresh a test without client-visible delays. > > When a test has expired, postscreen could refresh all unexpired > tests that will expire soon. For example, all tests that will expire > within one TTL of the expired test, or all tests that will expire > within one hour. This will not necessarily reduce the amount of > client-visible delays, but it will reduce the WHITELIST VETO logs. > >Wietse >
Re: postscreen MX Policy test and multiple listening IP addresses
/dev/rob0: > Jun 5 01:50:46 cardinal postfix/postscreen[15628]: CONNECT from > [174.37.3.121]:33695 to [216.23.247.74]:25 > Jun 5 01:50:52 cardinal postfix/postscreen[15628]: PASS OLD > [174.37.3.121]:33695 > Jun 5 01:50:52 cardinal postfix/smtpd[15816]: connect from > 174.37.3.121-static.reverse.softlayer.com[174.37.3.121] Host connects 01:50:46, postscreen logs "PASS OLD" at 01:50:52 and hands off the connection to smtpd. The six-second pause suggests that postscreen_greet_ttl (1d) expired (according to "postconf -n" your postscreen_mumble_ttl settings haven't changed). > Jun 5 01:50:53 cardinal postfix/postscreen[15628]: CONNECT from > [174.37.3.121]:52927 to [216.23.247.78]:25 > Jun 5 01:50:53 cardinal postfix/postscreen[15628]: WHITELIST VETO > [174.37.3.121]:52927 > It was whitelisted 7 seconds ago. Could that have expired? What 7 seconds? the "PASS OLD" action was logged 01:50:52. The new connection is made 01:50:53. Each postscreen test has its own TTL. Different tests have different costs (for sender and receiver), and therefore different tests expire at different times. You have the following time-dependent tests enabled: postscreen_bare_newline_action = enforce postscreen_dnsbl_action = enforce postscreen_greet_action = enforce Their expiration times are: postscreen_bare_newline_ttl = 30d postscreen_dnsbl_ttl = 1h postscreen_greet_ttl = 1d Clearly, they don't expire at the same time. The Postfix verify(8) daemon avoids client-visible delays by sending a new probe before a result expires (it has separate _refresh and _expire timing parameters). That trick does not work with postscreen. postscreen does not have separate _refresh and _expire settings because many postscreen tests are client-visible. For example, postscreen_greet is visible (6 seconds delay), postscreen_dnsbl almost invisible (less than 1 second, usually) and postscreen_bare_newline means the client gets 4XX replies if it passes the test. So, in the majority of tests it is not possible to refresh a test without client-visible delays. When a test has expired, postscreen could refresh all unexpired tests that will expire soon. For example, all tests that will expire within one TTL of the expired test, or all tests that will expire within one hour. This will not necessarily reduce the amount of client-visible delays, but it will reduce the WHITELIST VETO logs. Wietse
Re: Sending Bulk Mails
On 6/5/2011 8:36 AM, Wietse Venema wrote: > Stan Hoeppner: >> On 6/4/2011 6:25 AM, /dev/rob0 wrote: >> >>> My recommendation to the OP is to consider outsourcing this. It will >>> not cost that much, and a reputable email service provider can be >>> well worth what they charge. >>> >>> Conversely to do it inhouse I would recommend tearing it all down and >>> starting over with a recent and well-supported OS. It might look >>> cheaper on the short-term bottom line to beg on the Internet for help >>> in keeping the old install running, but when things go wrong, as they >>> surely will, the costs will skyrocket in ways not yet imagined. >> >> +1 >> >> Outsource the sending of these shareholder notifications to a reputable >> bulk mailer. Stating you are running an EOL OS and EOL Postfix tells us >> you are not up to the task of successfully pulling this operation off. > > Sorry, you can tell people they run old code, but there is no need > to say they are an idiot. The platform may lack some features, but > it is technically good for a 15k mail sending operation. The > recommendation to outsource has nothing to do with the software. "not up to the task of successfully pulling this operation off" does not equal, nor translate to saying "you are an idiot" There are plenty of smart people on the net who have been unsuccessful with their first (and 2nd, and 3rd) attempt at bulk mailing, as demonstrated by their frequent requests for help on anti spam mailing lists. The OP will apparently be attempting to send important financial information with his first bulk mailing attempt. The OP's mention of using very old SMTP software seems to indicate he hasn't been keeping up with the world of SMTP/internet mail, nor managing email system on a regular basis. My comment was not intended to be offensive, and I apologize as apparently it was to some. It was merely intended as smelling salt[1] under the nose of the OP. [1] http://en.wikipedia.org/wiki/Smelling_salts -- Stan
Re: postscreen MX Policy test and multiple listening IP addresses
On Sun, Jun 05, 2011 at 09:21:21AM -0400, Wietse Venema wrote: > /dev/rob0: > > On Fri, Jun 03, 2011 at 01:09:28PM -0400, Wietse Venema wrote: > > > postscreen_whitelist_interfaces matters only for clients that > > > are not yet whitelisted (or that have expired). > > > > Issue: previously whitelisted client gets WHITELIST VETO on > > secondary > > Of course, being whitelisted once is NOT a free pass forever. > > Check your postscreen_mumble_ttl settings. All at defaults: rob0@cardinal:~$ /usr/sbin/postconf | grep '^postscreen_.*_ttl' postscreen_bare_newline_ttl = 30d postscreen_dnsbl_ttl = 1h postscreen_greet_ttl = 1d postscreen_non_smtp_command_ttl = 30d postscreen_pipelining_ttl = 30d A little more log searching suggests that this was probably an expiration of postscreen_dnsbl_ttl. The previous connect was: Jun 5 00:50:47 cardinal postfix/postscreen[14788]: PASS OLD [174.37.3.121]:58603 and indeed on the secondary MX address. The one I posted hit the primary at 01:50:46, with PASS OLD at 01:50:52, then it hit the secondary at 01:50:53. If the one-hour timer started at 00:50:47, this makes sense. Just a semi-interesting little fluke, I guess. Another almost- interesting fact is that this client makes an attempt every hour, as if a cron job is running at :50 to try to flush the queue of the undoubtedly many undeliverable mails they have. :) -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Sending Bulk Mails
Stan Hoeppner: > On 6/4/2011 6:25 AM, /dev/rob0 wrote: > > > My recommendation to the OP is to consider outsourcing this. It will > > not cost that much, and a reputable email service provider can be > > well worth what they charge. > > > > Conversely to do it inhouse I would recommend tearing it all down and > > starting over with a recent and well-supported OS. It might look > > cheaper on the short-term bottom line to beg on the Internet for help > > in keeping the old install running, but when things go wrong, as they > > surely will, the costs will skyrocket in ways not yet imagined. > > +1 > > Outsource the sending of these shareholder notifications to a reputable > bulk mailer. Stating you are running an EOL OS and EOL Postfix tells us > you are not up to the task of successfully pulling this operation off. Sorry, you can tell people they run old code, but there is no need to say they are an idiot. The platform may lack some features, but it is technically good for a 15k mail sending operation. The recommendation to outsource has nothing to do with the software. Wietse
Re: postscreen MX Policy test and multiple listening IP addresses
/dev/rob0: > On Fri, Jun 03, 2011 at 01:09:28PM -0400, Wietse Venema wrote: > > postscreen_whitelist_interfaces matters only for clients that are > > not yet whitelisted (or that have expired). > > Issue: previously whitelisted client gets WHITELIST VETO on secondary Of course, being whitelisted once is NOT a free pass forever. Check your postscreen_mumble_ttl settings. Wietse
Re: Sending Bulk Mails
Am 05.06.2011 14:30, schrieb Jerry: > On Sun, 05 Jun 2011 05:52:53 -0500 > Stan Hoeppner articulated: >> +1 >> >> Outsource the sending of these shareholder notifications to a >> reputable bulk mailer. Stating you are running an EOL OS and EOL >> Postfix tells us you are not up to the task of successfully pulling >> this operation off. > IMHO, your vexatious comment to the OP was uncalled for. No > I know individuals driving around in vintage 1950's cars. > Perhaps they should get off the highway because they are not > the latest models either. they ARE taken off if they are unsecure because on public streets you can not drive with unmaintained cars the same should be true for the internet > certainly agree that using the latest software might be advantageous; > to ridicule or call an individual incompetent simple because for their > own personal reasons they choose not to is uncalled for. you do not realize the difference between "latest" and "not maintained" > I am assuming that all of the software you use is absolutely the latest > version available and your PC(s) are all the latest models. None of last > year's or month's crap is being used I assume. stoopid argument as long tehre are upstream fixes all is ok using computers with software form a mueseum is as long a personal problem as the machine has no internet access using outdated software on servers is simply unfair against all others which have do deal with the results of all the zombie-machines out there signature.asc Description: OpenPGP digital signature
Re: Sending Bulk Mails
On Sun, 05 Jun 2011 05:52:53 -0500 Stan Hoeppner articulated: > On 6/4/2011 6:25 AM, /dev/rob0 wrote: > > > My recommendation to the OP is to consider outsourcing this. It > > will not cost that much, and a reputable email service provider can > > be well worth what they charge. > > > > Conversely to do it inhouse I would recommend tearing it all down > > and starting over with a recent and well-supported OS. It might > > look cheaper on the short-term bottom line to beg on the Internet > > for help in keeping the old install running, but when things go > > wrong, as they surely will, the costs will skyrocket in ways not > > yet imagined. > > +1 > > Outsource the sending of these shareholder notifications to a > reputable bulk mailer. Stating you are running an EOL OS and EOL > Postfix tells us you are not up to the task of successfully pulling > this operation off. A Neandertal with a sharpened rock attached to the end of a short stick might not be up to the task of waging modern warfare; however, I certainly would not want to get hit on the head with his weapon. IMHO, your vexatious comment to the OP was uncalled for. I know individuals driving around in vintage 1950's cars. Perhaps they should get off the highway because they are not the latest models either. While I certainly agree that using the latest software might be advantageous; to ridicule or call an individual incompetent simple because for their own personal reasons they choose not to is uncalled for. I am assuming that all of the software you use is absolutely the latest version available and your PC(s) are all the latest models. None of last year's or month's crap is being used I assume. At least "/dev/rob0" gave the OP a cautious and useful suggestion. Your reply is what I would expect on Slashdot. -- 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: Sending Bulk Mails
On 6/4/2011 6:25 AM, /dev/rob0 wrote: > My recommendation to the OP is to consider outsourcing this. It will > not cost that much, and a reputable email service provider can be > well worth what they charge. > > Conversely to do it inhouse I would recommend tearing it all down and > starting over with a recent and well-supported OS. It might look > cheaper on the short-term bottom line to beg on the Internet for help > in keeping the old install running, but when things go wrong, as they > surely will, the costs will skyrocket in ways not yet imagined. +1 Outsource the sending of these shareholder notifications to a reputable bulk mailer. Stating you are running an EOL OS and EOL Postfix tells us you are not up to the task of successfully pulling this operation off. -- Stan
