Re: smtpd_sasl_security_options clarification

2016-07-12 Thread Wietse Venema
Wietse: > > You can find out about SASL active etc. attacks in RFC 4422 > > https://tools.ietf.org/html/rfc4422 > Michael Fox: > Thanks. Yes, that describes the attack categories. But it doesn't answer > the above question. Is the categorization documented somewhere? If not, > how are we to kn

This ought to be simple to stop. Am I missing something?

2016-07-12 Thread Phil Stracchino
I'm getting spam leaking through from sites with non-resolving IP or invalid DNS, sending mail to myself as me. Here's an example: Jul 12 08:03:52 minbar postfix/smtpd[17824]: warning: hostname static.vnpt.vn does not resolve to address 14.167.212.244 Jul 12 08:03:52 minbar postfix/smtpd[17824]:

Re: This ought to be simple to stop. Am I missing something?

2016-07-12 Thread Wietse Venema
> smtpd_sender_restrictions = > permit_mynetworks permit_tls_clientcerts permit_sasl_authenticated > reject_invalid_hostname > reject_unknown_sender_domain > reject_non_fqdn_sender check_sender_access hash:/etc/postfix/block-local-sender /etc/postfix

Re: This ought to be simple to stop. Am I missing something?

2016-07-12 Thread Bill Cole
On 12 Jul 2016, at 9:14, Phil Stracchino wrote: I'm getting spam leaking through from sites with non-resolving IP or invalid DNS, sending mail to myself as me. You COULD use reject_unknown_client_hostname but it has substantial false positives. More directly, you could enforce your own SPF

Re: This ought to be simple to stop. Am I missing something?

2016-07-12 Thread Phil Stracchino
On 07/12/16 10:30, Bill Cole wrote: > On 12 Jul 2016, at 9:14, Phil Stracchino wrote: > >> I'm getting spam leaking through from sites with non-resolving IP or >> invalid DNS, sending mail to myself as me. > > You COULD use reject_unknown_client_hostname but it has substantial > false positives.

RE: smtpd_sasl_security_options clarification

2016-07-12 Thread Michael Fox
> > This is standard terminology, and therefore not defined in either > Postfix or SASL RFC. > > Active network attack: an attacker modifies the communication between > parties. > > Mutual authentication: each party authenticates to the other party. Thanks. But again, the question is *NOT* abo

Re: smtpd_sasl_security_options clarification

2016-07-12 Thread Peter
On 13/07/16 15:38, Michael Fox wrote: > Thanks. But again, the question is *NOT* about the terminology or the > general meaning or definition of the categories. The question is > specifically asking which authentication mechanisms Postfix places in those > categories. I think the actual security

Re: smtpd_sasl_security_options clarification

2016-07-12 Thread Peter
On 13/07/16 15:56, Peter wrote: > On 13/07/16 15:38, Michael Fox wrote: >> Thanks. But again, the question is *NOT* about the terminology or the >> general meaning or definition of the categories. The question is >> specifically asking which authentication mechanisms Postfix places in those >> ca

RE: smtpd_sasl_security_options clarification

2016-07-12 Thread Michael Fox
> > > > I think the actual security features list is dependant on the SASL > > implementation, and which mechs satisfy each security feature is defined > > in cyrus and dovecot sasl. Ah. So you're saying that for each auth mechanism configured in the SASL implementation (dovecot in my case), the

Re: smtpd_sasl_security_options clarification

2016-07-12 Thread Peter
On 13/07/16 16:30, Michael Fox wrote: > Ah. So you're saying that for each auth mechanism configured in the SASL > implementation (dovecot in my case), the SASL implementation is sending > Postfix a tuple which includes the mechanism name and which categories it > fits into, rather than Postfix ke

RE: smtpd_sasl_security_options clarification

2016-07-12 Thread Michael Fox
> Yes, again from the quote from Wietse that you snipped out: > > > Dovecot tells Postfix the supported mechanism names and their > > security properties. O.K. Thanks. I read but did not understand the quote above. Your explanation was clearer and I understood it the first time. Thanks again,

Re: This ought to be simple to stop. Am I missing something?

2016-07-12 Thread Bill Cole
On 12 Jul 2016, at 15:44, Phil Stracchino wrote: On 07/12/16 10:30, Bill Cole wrote: On 12 Jul 2016, at 9:14, Phil Stracchino wrote: I'm getting spam leaking through from sites with non-resolving IP or invalid DNS, sending mail to myself as me. You COULD use reject_unknown_client_hostname b

auth/tls combinations sanity check

2016-07-12 Thread Michael Fox
I have a possibly unusual AUTH/TLS combination requirement. As a newbie, I could use a sanity check. Requirements: * All virtual mail clients will use SASL AUTH * Virtual mail clients on specific internal networks MUST NOT be offered TLS. This is to satisfy FCC requirements prohibiting the use o

Re: This ought to be simple to stop. Am I missing something?

2016-07-12 Thread lists
‎Hopefully this won't be interpreted as thread hijacking, but can you elaborate of this? --- reject_rbl_client zen.spamhaus.org=127.0.0.2, reject_rbl_client zen.spamhaus.org=127.0.0.3, reject_rbl_client zen.spamhaus.org=127.0.0.4, reject_rbl_client zen.spamhaus.org=127.0.0.10, reject_rbl_clien

RE: This ought to be simple to stop. Am I missing something?

2016-07-12 Thread L . P . H . van Belle
A good combination of rbl lists with postscreen im using. postscreen_dnsbl_threshold=4 postscreen_dnsbl_sites = b.barracudacentral.org*4 bad.psky.me*4 zen.spamhaus.org*4 dnsbl.cobion.com*2 bl.spameatingmonkey.net*2 fresh.spameatingmonkey.net*2