postfix rejecting botnet mail as intended -- is this a reasonable server load, or is there more config to do?

2014-05-17 Thread grantksupport
Hello, I routinely see 'pulses' of the following traffic, from myriad IPs around the planet, hitting my mailservers' postfix front-ends: ... May 15 09:02:12 mx postfix/smtpd[26321]: connect from unknown[69.198.138.134] May 15 09:02:12 mx postfix/smtpd[26321]: NOQUEUE: reject: RCPT from unknown[69

Re: postfix rejecting botnet mail as intended -- is this a reasonable server load, or is there more config to do?

2014-05-17 Thread grantksupport
Hello On Sat, May 17, 2014, at 09:21 AM, li...@rhsoft.net wrote: > in the case above you can set "reject_non_fqdn_helo_hostname" > before the RBL in your restrictions which needs also change > "smtpd_helo_required " to yes to be effective I'm pretty sure I already have that set correctly. I'll re

Re: postfix rejecting botnet mail as intended -- is this a reasonable server load, or is there more config to do?

2014-05-17 Thread grantksupport
Hello On Sat, May 17, 2014, at 09:23 AM, Viktor Dukhovni wrote: > > I understand this is likely botnet-generated traffic. They occur all > > day long, typically ~1-10 times/minute. > > Typical input capacity of a Postfix mail server is over 100 messages > per second (sometimes 10s of messages pe

Re: postfix rejecting botnet mail as intended -- is this a reasonable server load, or is there more config to do?

2014-05-17 Thread grantksupport
Hello, On Sat, May 17, 2014, at 09:37 AM, li...@rhsoft.net wrote: > peaks of 100 rejected messages per minute is *nothing* > frankly you can receive 100 messages per minute with no real load > > we have days with 120 rejected messages on a Barracuda appliance > which in many cases even reveic

Re: postfix rejecting botnet mail as intended -- is this a reasonable server load, or is there more config to do?

2014-05-17 Thread grantksupport
On Sat, May 17, 2014, at 09:58 AM, li...@rhsoft.net wrote: > looks fine, i would place the following on top! > > reject_non_fqdn_recipient > reject_non_fqdn_sender > reject_unlisted_sender > > you usually don't want non-full-qualified addresses or invalid senders > even in case of authenticated

Re: Opportunistic TLS vs. plain

2014-06-21 Thread grantksupport
On Sat, Jun 21, 2014, at 10:07 AM, Viktor Dukhovni wrote: > > During a security audit, it was determined that the MX supported what > > the auditors called "weak" ciphers and protocols (SSLv3, TLSv1.0, > > RC4-MD5, anonymous ciphers and so on). The auditors demanded that we > > disable all those -

Re: Opportunistic TLS vs. plain

2014-06-21 Thread grantksupport
hi On Sat, Jun 21, 2014, at 10:36 AM, Viktor Dukhovni wrote: > The *default* Postfix TLS cipherlist settings are chosen with care. > Best pracice is to leave them as-is. > > See also: > > http://www.postfix.org/FORWARD_SECRECY_README.html Right. That's one of the specific documents I'd alr

Re: Opportunistic TLS vs. plain

2014-06-21 Thread grantksupport
On Sat, Jun 21, 2014, at 11:41 AM, Viktor Dukhovni wrote: > I repeat, these aren't the droids you're looking for. ok, no longer looking for those droids. returning to why I started looking for them in the 1st place, trying to understand/control the strength of encryption to/from my server, maki

Re: Opportunistic TLS vs. plain

2014-06-21 Thread grantksupport
Viktor, > Your server is fine. Google is using RC4 outbound, and it is their > responsibility to improve that, not yours. Thanks, for the pointers. That's cleared up & understood now. On Sat, Jun 21, 2014, at 01:35 PM, Wietse Venema wrote: > Instead of tinkering with carefully-chosen Postfix d