Re: limiting outgoing

2012-01-14 Thread Robert Schetterer
Am 14.01.2012 04:40, schrieb Benny Pedersen:
 On Thu, 12 Jan 2012 17:31:17 +0100, Jiri Vitek wrote:
 
 slow_destination_concurrency_limit = 2
 slow_destination_concurrency_limit = 2
 
 ymvw, only one line is needed :)
 
 
 

ups , yes youre right, some copy paste stuff
thx !!!

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria


Re: smtpd_sasl_security_options = noanonymous, CRAM-MD5

2012-01-14 Thread bilal ghayyad
Thanks a lot for your advise.

What is the difference between noplaintext and the plaintext encrypted?

Also, what will happen if I did not set this mech_list: cram-md5? For what it 
used the cram-md5?

Regards
Bilal

--- On Fri, 1/13/12, Patrick Ben Koetter p...@state-of-mind.de wrote:

 From: Patrick Ben Koetter p...@state-of-mind.de
 Subject: Re: smtpd_sasl_security_options = noanonymous, CRAM-MD5
 To: postfix-users@postfix.org
 Date: Friday, January 13, 2012, 6:03 PM
 * bilal ghayyad bilmar...@yahoo.com:
  Hi All;
  
  If I set smtpd_sasl_security_options = CRAM-MD5
 instead of noanonymous, then what will happen in this case?
 
 The server will throttle. CRAM-MD5 is not a valid option
 for
 smtpd_sasl_security_options.
 
 Set this instead:
 
 # main.cf
 smtpd_sasl_security_options = noanonymous, noplaintext
 
 # smtpd.conf
 mech_list: cram-md5
 
 
  And if I used: smtpd_use_tls = yes and did not use
 certificate, then they
  password will be sent encrypted or not?
 
 This forces TLS on all clients. You must not do it on a
 publicly available MX
 according to RFCs.
 
  Also, what if I used this also? smtpd_tls_auth_only =
 yes
 
 You want noplaintext over unencrypted channels and
 plaintext over crypted,
 yes? Try this in main.cf:
 
 smtpd_sasl_security_options = noanonymous, noplaintext
 smtpd_tls_sasl_security_options = noanonymous
 
 
  Is it possible to set all togethor? How it will work
 in this case:
 
 Use my examples from above.
 
 p@rick
 
 -- 
 All technical questions asked privately will be
 automatically answered on the
 list and archived for public access unless privacy is
 explicitely required and
 justified.
 
 saslfinger (debugging SMTP AUTH):
 http://postfix.state-of-mind.de/patrick.koetter/saslfinger/
 


Re: smtpd_sasl_security_options = noanonymous, CRAM-MD5

2012-01-14 Thread bilal ghayyad
Dear Patric;

What I have to set mech_list: in the smtpd.conf if I used the below commands? 
And do I need to restart postfix service after do a changes in smtpd.conf?

smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_tls_sasl_security_options = noanonymous


Currently I see the following logs (still did not configure the dovecot):

Jan 14 06:02:02 localhost dovecot: pop3-login: Login: user=bghayad, 
method=PLAIN, rip=78.154.199.70, lip=207.150.197.37
Jan 14 06:02:02 localhost dovecot: POP3(bghayad): mail_location not set and 
autodetection failed: Mail storage autodetection failed with home=/home/bghayad
Jan 14 06:02:02 localhost dovecot: Fatal: POP3(bghayad): Namespace 
initialization failed
Jan 14 06:02:02 localhost postfix/smtpd[2509]: warning: 
xsasl_cyrus_server_get_mechanism_list: no applicable SASL mechanisms
Jan 14 06:02:02 localhost postfix/smtpd[2509]: fatal: no SASL authentication 
mechanisms
Jan 14 06:02:03 localhost postfix/master[2120]: warning: process 
/usr/libexec/postfix/smtpd pid 2509 exit status 1
Jan 14 06:02:03 localhost postfix/master[2120]: warning: 
/usr/libexec/postfix/smtpd: bad command startup -- throttling


Regards
Bilal





Regards
Bilal
--- On Fri, 1/13/12, Patrick Ben Koetter p...@state-of-mind.de wrote:

 From: Patrick Ben Koetter p...@state-of-mind.de
 Subject: Re: smtpd_sasl_security_options = noanonymous, CRAM-MD5
 To: postfix-users@postfix.org
 Date: Friday, January 13, 2012, 6:03 PM
 * bilal ghayyad bilmar...@yahoo.com:
  Hi All;
  
  If I set smtpd_sasl_security_options = CRAM-MD5
 instead of noanonymous, then what will happen in this case?
 
 The server will throttle. CRAM-MD5 is not a valid option
 for
 smtpd_sasl_security_options.
 
 Set this instead:
 
 # main.cf
 smtpd_sasl_security_options = noanonymous, noplaintext
 
 # smtpd.conf
 mech_list: cram-md5
 
 
  And if I used: smtpd_use_tls = yes and did not use
 certificate, then they
  password will be sent encrypted or not?
 
 This forces TLS on all clients. You must not do it on a
 publicly available MX
 according to RFCs.
 
  Also, what if I used this also? smtpd_tls_auth_only =
 yes
 
 You want noplaintext over unencrypted channels and
 plaintext over crypted,
 yes? Try this in main.cf:
 
 smtpd_sasl_security_options = noanonymous, noplaintext
 smtpd_tls_sasl_security_options = noanonymous
 
 
  Is it possible to set all togethor? How it will work
 in this case:
 
 Use my examples from above.
 
 p@rick
 
 -- 
 All technical questions asked privately will be
 automatically answered on the
 list and archived for public access unless privacy is
 explicitely required and
 justified.
 
 saslfinger (debugging SMTP AUTH):
 http://postfix.state-of-mind.de/patrick.koetter/saslfinger/
 


Re: smtpd_sasl_security_options = noanonymous, CRAM-MD5

2012-01-14 Thread /dev/rob0
Please do not top-post your replies here. Thank you.

On Saturday 14 January 2012 06:04:10 bilal ghayyad wrote:
 What I have to set mech_list: in the smtpd.conf if I used the below
 commands? And do I need to restart postfix service after do a
 changes in smtpd.conf?

smtpd.conf is a Cyrus SASL thing ...

 smtpd_sasl_security_options = noanonymous, noplaintext
 smtpd_tls_sasl_security_options = noanonymous
 
 
 Currently I see the following logs (still did not configure the
 dovecot):
 
 Jan 14 06:02:02 localhost dovecot: pop3-login: Login:
 user=bghayad, method=PLAIN, rip=78.154.199.70,

... and it makes no sense to be using Cyrus SASL when you are also 
using Dovecot.

http://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL
http://www.postfix.org/SASL_README.html#server_dovecot

I suggest starting over from the guidelines in those links.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if /dev/rob0 is in the Subject:


Re: Stan's List [was: free antivirus scanner ?]

2012-01-14 Thread Charles Marcus

On 2012-01-13 6:05 PM, Stan Hoeppner s...@hardwarefreak.com wrote:

On 1/13/2012 2:13 PM, email builder wrote:

  We use a modified version as a HELO blacklist. This avoids the false



Interesting... can you provide specific details on what you mean by
'modified version'?



I second that.  I'm feeling convinced enough to use it as it was
intended, BUT ideally, I don't desire rejecting even those stubborn
people who insist on running their email server from their bedroom
without relaying through their ISP.



Used as intended fqrdns.pcre will definitely block the bedroom email
servers doing direct-to-MX, because odds are high that his parents' PC
or little sister's PC are infected with a spam bot, which again is the
purpose of this table.  Thus, if that is really your desire, you don't
want to use this table.  You're better off using Postscreen.


I was more interested in what specific changes he made in order to use 
it as a HELO blacklist, and how and why it avoided false positives when 
it is used the way we have been using it


--

Best regards,

Charles


Re: postscreen supersedes fqrdns.pcre table

2012-01-14 Thread Charles Marcus

On 2012-01-13 6:18 PM, Stan Hoeppner s...@hardwarefreak.com wrote:

As fqrdns.pcre has been a topic recently, I feel this needs to be stated
again, for those of you who have missed previous threads on this topic.

1.  Postscreen rejects most bots BEFORE they reach smtpd processes
 (fqrdns.pcre is evaluated by smtpd)
2.  AFAIK postscreen never FP's
3.  postscreen consumes very little resources

*Therefore postscreen is preferred over fqrdns.pcre for rejecting bots.*

You can still run fqrdns.pcre in tandem behind postscreen, in
smtpd_*_restrictions, but it will likely reject few bots.  It may
however still block non-bot spam coming direct to MX from
consumerish/broadband sources.

For those not running postscreen, fqrdns.pcre will work as it always has.


I'd be *very* interested in seeing some stats from a *busy* server, to 
see how many hits - if any - fqrdns.pcre has running behind postscreen...


Also, Stan - would would be interested in seeing some comparisons of 
postscreen configurations. I haven't implemented it yet (we use an 
outsourced anti-spam service currently), but am interested in trying it 
out to see if we can lose that service permanently now.


--

Best regards,

Charles


Re: Strange SASL Authentication Issue

2012-01-14 Thread lst_hoe02

Zitat von Robert Krig robert.k...@render-wahnsinn.de:




On 01/13/2012 09:52 AM, lst_ho...@kwsoft.de wrote:

Zitat von Robert Krig robert.k...@render-wahnsinn.de:




On 01/11/2012 08:38 PM, Gary Smith wrote:

Restarting postfix, saslauthd and authdaemon seems to get it
working again,
at least for a while.


Are you using pam_mysql by chance?


Yes, I am.


Too bad, pam_mysql is known to leak memory. We have used it some time
ago and the only option to get it stable was with saslauthd -n 0.

Regards

Andreas




So far it's been running stable, memorywise by using the -c flag for
cacheing. Is there any downside to the -n 0 flag? I had read about
before, but I wanted to see if cacheing alone made a difference.


The downside of -n 0 is that for every authentication request a new  
process is spawned and ended afterwards so the memory leak will not  
sum up. This will hit performance limits because of init costs  
(process startup, db-connection etc.) if your authentication rate is  
very high. For small/mid-size systems it should not matter that much.


Regards

Andreas





smime.p7s
Description: S/MIME Cryptographic Signature


Re: smtpd_sasl_security_options = noanonymous, CRAM-MD5

2012-01-14 Thread bilal ghayyad
OK thanks, so no need for Cyrus SASL if I am going to use Dovecot?

But why the noplaintext is not working? What is the missing libraries or 
mechanism that I have to install or add?

One more thing, I telnet for the smpt server and I did not see the TLS stated, 
although I have the following configuration in the main.cf:

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous

So, any missing for a package to be installed?


Regards
Bilal

--- On Sat, 1/14/12, /dev/rob0 r...@gmx.co.uk wrote:

 From: /dev/rob0 r...@gmx.co.uk
 Subject: Re: smtpd_sasl_security_options = noanonymous, CRAM-MD5
 To: postfix-users@postfix.org
 Date: Saturday, January 14, 2012, 7:16 AM
 Please do not top-post your replies
 here. Thank you.
 
 On Saturday 14 January 2012 06:04:10 bilal ghayyad wrote:
  What I have to set mech_list: in the smtpd.conf if I
 used the below
  commands? And do I need to restart postfix service
 after do a
  changes in smtpd.conf?
 
 smtpd.conf is a Cyrus SASL thing ...
 
  smtpd_sasl_security_options = noanonymous,
 noplaintext
  smtpd_tls_sasl_security_options = noanonymous
  
  
  Currently I see the following logs (still did not
 configure the
  dovecot):
  
  Jan 14 06:02:02 localhost dovecot: pop3-login: Login:
  user=bghayad, method=PLAIN,
 rip=78.154.199.70,
 
 ... and it makes no sense to be using Cyrus SASL when you
 are also 
 using Dovecot.
 
 http://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL
 http://www.postfix.org/SASL_README.html#server_dovecot
 
 I suggest starting over from the guidelines in those
 links.
 -- 
   http://rob0.nodns4.us/ -- system administration and
 consulting
   Offlist GMX mail is seen only if /dev/rob0 is in
 the Subject:



Is it required to have the cert to be able to use TLS?

2012-01-14 Thread bilal ghayyad
Hi All;

Is it required to have the cert to be able to use the TLS?

To be able to use noplaintext, what is required for this to be existed?

Regards
Bilal


Re: Is it required to have the cert to be able to use TLS?

2012-01-14 Thread Peter L. Berghold
On Sat, 2012-01-14 at 05:52 -0800, bilal ghayyad wrote:

 Is it required to have the cert to be able to use the TLS?


Short answer:  yes

More detail:  this can either be a self signed cert or one purchased
from any number of cert suppliers.  Problem with a self signed cert is
nobody is going to trust it since it is not traceable to a known CA. 

 To be able to use noplaintext, what is required for this to be existed?
 

Plain text as you put it or unsecured SMTP will work out of the box
with some minor configuration.

Before you set up an MTA though, do a lot of research first and make
sure you know what you are doing. There's a lot of ways to set up an MTA
badly..

-- 
Peter L. Berghold   Brewer, Dog enthusiast, Crazy Cook



Re: Is it required to have the cert to be able to use TLS?

2012-01-14 Thread Wietse Venema
bilal ghayyad:
 Hi All;
 
 Is it required to have the cert to be able to use the TLS?

It depends primarily on the role: client or server.

 To be able to use noplaintext, what is required for this to be existed?

This is described in http://www.postfix.org/TLS_README.html.
If the document is incomplete please send suggestions.

Wietse


Re: Is it required to have the cert to be able to use TLS?

2012-01-14 Thread bilal ghayyad

Plain text as you put it or unsecured SMTP will work out of the box with some 
minor configuration.

* I was asking about using noplaintext and not plain, so how I can use 
noplaintext? Is there any required package to be installed at the server?

Regards
Bilal


--- On Sat, 1/14/12, Peter L. Berghold pe...@berghold.net wrote:

 From: Peter L. Berghold pe...@berghold.net
 Subject: Re: Is it required to have the cert to be able to use TLS?
 To: bilal ghayyad bilmar...@yahoo.com
 Cc: postfix-users@postfix.org
 Date: Saturday, January 14, 2012, 9:00 AM
 On Sat, 2012-01-14 at 05:52 -0800,
 bilal ghayyad wrote:
 
  Is it required to have the cert to be able to use the
 TLS?
 
 
 Short answer:  yes
 
 More detail:  this can either be a self signed cert or
 one purchased
 from any number of cert suppliers.  Problem with a
 self signed cert is
 nobody is going to trust it since it is not traceable to a
 known CA. 
 
  To be able to use noplaintext, what is required for
 this to be existed?
  
 
 Plain text as you put it or unsecured SMTP will work out
 of the box
 with some minor configuration.
 
 Before you set up an MTA though, do a lot of research first
 and make
 sure you know what you are doing. There's a lot of ways to
 set up an MTA
 badly..
 
 -- 
 Peter L. Berghold       
    Brewer, Dog enthusiast, Crazy Cook
 



Re: Stan's List [was: free antivirus scanner ?]

2012-01-14 Thread Stan Hoeppner
On 1/14/2012 6:40 AM, Charles Marcus wrote:

 I was more interested in what specific changes he made in order to use
 it as a HELO blacklist, and how and why it avoided false positives when
 it is used the way we have been using it

It wouldn't really require any changes.  You could use it with
check_helo_access as is.   The reason it avoids FPs in this usage is
just what he stated:  legit MTAs with generic rDNS are going to HELO
with a real hostname, not the rDNS string.

-- 
Stan





Re: postscreen supersedes fqrdns.pcre table

2012-01-14 Thread Stan Hoeppner
On 1/14/2012 6:43 AM, Charles Marcus wrote:

 Also, Stan - would would be interested in seeing some comparisons of
 postscreen configurations. I haven't implemented it yet (we use an
 outsourced anti-spam service currently), but am interested in trying it
 out to see if we can lose that service permanently now.

Neither is a complete antispam solution.  You'll need a lot more special
sauce in a local AS recipe before you'd want to wholesale switch from
the managed service.

-- 
Stan


Re: Postfix 2.9 feature freeze for stable release

2012-01-14 Thread Wietse Venema
Wietse Venema:
  Expect to see a stable Postfix 2.9 release in a few weeks from now.
 
 I've put out snapshot 20120110 yesterday. This improves the logging
 of various table lookup errors, fixes too verbose logging in the
 memcache client during cache cleanup, and continues the effort to
 turn fatal table lookup/update errors into warnings (graceful
 degradation).

Postfix snapshot 20120114 cleans up error handling such that a
daemon process will keep running even when a lookup table can't be
opened.

Instead of terminating immediately with a fatal error, the daemon
process continues execution with reduced functionality, and keeps
providing service that does not depend on the missing table.  This
gradual degradation approach may be more user-friendly (or
admin-friendly). There is a backwards-compatibility switch if the
old behavior is needed (see RELEASE_NOTES).

Everything else should work as it did before.

This facelift has not yet been applied to postscreen, which still
has the more spartan way of error handling.

Wietse