Re: limiting outgoing

[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

[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  wrote:

> From: Patrick Ben Koetter 
> Subject: Re: smtpd_sasl_security_options = noanonymous, CRAM-MD5
> To: postfix-users@postfix.org
> Date: Friday, January 13, 2012, 6:03 PM
> * bilal ghayyad :
> > 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):
> 
> 

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

[DTNX/NGMX Postmaster]

On 13 jan. 2012, at 21:13, email builder wrote:

>>> We use a modified version as a HELO blacklist. This avoids the false
>>> positives we saw while testing it as a reverse DNS restriction but,
>>> because the use of the reverse hostname as the HELO string is a
>>> common pattern in spam attempts from compromised hosts, it's still
>>> very effective.
>> 
>> 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.
> 
> Do you have a script that modifies the list into whatever format your
> method requires?
> 
> Does anyone have any comments on the efficacy of this method?
> 
> I assume all it would take is for bots to change the way they
> create their HELO hostname to bypass this.

The modifications are rather basic, really.

We've commented out some lines that were giving us false positives,
and modified the REJECT message to match its context, as well as
adding the error code we use for post processing and the like.

Legitimate mail servers aren't an issue for us, since they do not
use the reverse DNS string as their HELO greeting, and therefore 
they do not get rejected. They might get rejected for other reasons
(hello 'sbs2003.local'!) but that's not during this step.

It's currently maintained by hand, as automating it would take
more time that it'd save right now. Premature optimization etc.

As for bots changing their habits, I am not worried. New patterns
do emerge at times, but old habits die hard. If at some point it
turns out that it is no longer as effective, like after an upgrade
to 2.8 or higher, it will be reevaluated.

Cya,
Jona

--

P.S.: As for false positives, we had to comment out the following;

/^dd[1-9][0-9]{3,5}\.kasserver\.com$/
/^h[1-9][0-9]{3,7}\.stratoserver\.net$/

They are the default HELO strings for DS/VPS providers here in
Europe. The reverse DNS has often been updated to match the
domain name of the main website or whatever, so it tends to be
unique to our way of using the list.

We have tried in the past to get people to update their HELO, but
that turned out to be futile, and the amount of FPs we get from
it are higher than the spam attempts blocked.

Hence their removal from the list. YMMV, of course :-)

Re: smtpd_sasl_security_options = noanonymous, CRAM-MD5

[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=, 
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  wrote:

> From: Patrick Ben Koetter 
> Subject: Re: smtpd_sasl_security_options = noanonymous, CRAM-MD5
> To: postfix-users@postfix.org
> Date: Friday, January 13, 2012, 6:03 PM
> * bilal ghayyad :
> > 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):
> 
> 

Re: smtpd_sasl_security_options = noanonymous, CRAM-MD5

[/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=, 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 ?]

[Charles Marcus]

On 2012-01-13 6:05 PM, Stan Hoeppner  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

[Charles Marcus]

On 2012-01-13 6:18 PM, Stan Hoeppner  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

[lst_hoe02]

Zitat von Robert Krig :




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

Zitat von Robert Krig :




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

[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  wrote:

> From: /dev/rob0 
> 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=, 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?

[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?

[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?

[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?

[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  wrote:

> From: Peter L. Berghold 
> Subject: Re: Is it required to have the cert to be able to use TLS?
> To: "bilal ghayyad" 
> 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 ?]

[Noel Jones]

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
> 

To use it as a HELO blacklist, you simply call it with
  check_helo_access pcre:/path/to/file

This is less likely to have FPs since most mail admins will not use
a dynamic-looking rDNS as their HELO hostname.

Many bots apparently are coded to use the rDNS as their HELO; it
will catch those.

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

[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

[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

[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