Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Understanding Postfix and smtpd_recipient_restrictions priorities

112 views
Skip to first unread message

RaSca

unread,
Jan 13, 2010, 12:02:38 PM1/13/10
to
Hi all,
I've got a setup with Debian Lenny, Postfix with MySQL(on a remote
server in the same LAN of the mail server) and Clamav+Spamassassin.
The original smtpd_recipient_restrictions parameter setting was this one:

smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_invalid_hostname

Spamassassin is configured with rbl check and so those lists were never
considered in Postfix... Until now.
Some days ago we started to serve a mail domain with a large amount of
spam and after that the Mysql database broke up with the message "Too
many connections".
The cause of this problem (as we saw from the logs) was that for any
spam message which was directed to a nonexistent mail address (but with
a correct domain) a connection to the db was also generated.
We've tried to find out a solution by adding some rbl checks directly in
Postfix:

smtpd_recipient_restrictions =
reject_non_fqdn_recipient,
reject_non_fqdn_sender,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_invalid_helo_hostname,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client list.dsbl.org,
reject_rbl_client rbl.mail-abuse.org,
reject_rbl_client spamsources.fabel.dk,
reject_unlisted_recipient

putting "reject_unlisted_recipient" after all the rbl check drastically
reduced the db connections, but after some time the Postfix process has
stopped working.
We saw the process up with a "ps", but it was not accepting mail
anymore. The only solution was to manually restart the Postfix daemon.

To find out a solution we recompiled and installed the 2.6.5 Postfix
release (with vda patch, instead of the default Lenny 2.5.5) and after
that the Postfix process went down just a time in a day, but it was not
necessary to restart the daemon. The original process become responsive
again by itself.

So the questions are: what the problems may be? Are they caused just by
the amount of messages the mail server must manage? Why a new version
seems to solve the problem? Are the priorities configured in the
smtpd_recipient_restrictions parameters correct?

Thanks for your help,

--
RaSca
Mia Mamma Usa Linux: Niente è impossibile da capire, se lo spieghi bene!
ra...@miamammausalinux.org
http://www.miamammausalinux.org

Steve

unread,
Jan 13, 2010, 12:09:35 PM1/13/10
to

-------- Original-Nachricht --------
> Datum: Wed, 13 Jan 2010 18:02:38 +0100
> Von: RaSca <ra...@miamammausalinux.org>
> An: postfi...@postfix.org
> Betreff: Understanding Postfix and smtpd_recipient_restrictions priorities

I would suggest you to use proxy maps to lower the amount of connections to the MySQL backend.

And on the above smtpd_recipient_restrictions I would suggest to push reject_unlisted_recipient above all RBL checks since there is no benefit in checking RBLs if you are anyway going to reject them later (if the recipient is not managed on your system).

I as well would not use zen.spamhaus.org (without a subscription) if you have a high mail volume.

> Thanks for your help,
>
> --
> RaSca

> Mia Mamma Usa Linux: Niente � impossibile da capire, se lo spieghi bene!
> ra...@miamammausalinux.org
> http://www.miamammausalinux.org

--
Preisknaller: GMX DSL Flatrate f�r nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02

RaSca

unread,
Jan 13, 2010, 12:32:15 PM1/13/10
to
Il giorno Mer 13 Gen 2010 18:09:35 CET, Steve ha scritto:
[...]

> I would suggest you to use proxy maps to lower the amount of connections to the MySQL backend.
> And on the above smtpd_recipient_restrictions I would suggest to push reject_unlisted_recipient above all RBL checks since there is no benefit in checking RBLs if you are anyway going to reject them later (if the recipient is not managed on your system).
> I as well would not use zen.spamhaus.org (without a subscription) if you have a high mail volume.

Thank you Steve,
I made as you suggested and now the MySQL threads still remains low even
if reject_unlisted_recipient is on the top of the list.
I also removed smahaus.org from the rbl check, I'm going to find out if
it's conveninet subscribing to the service.

Thanks a lot!

--
RaSca
Mia Mamma Usa Linux: Niente è impossibile da capire, se lo spieghi bene!
ra...@miamammausalinux.org
http://www.miamammausalinux.org

Brian Evans - Postfix List

unread,
Jan 13, 2010, 12:52:58 PM1/13/10
to
On 1/13/2010 12:32 PM, RaSca wrote:
> Il giorno Mer 13 Gen 2010 18:09:35 CET, Steve ha scritto:
> [...]
>> I would suggest you to use proxy maps to lower the amount of
>> connections to the MySQL backend. And on the above
>> smtpd_recipient_restrictions I would suggest to push
>> reject_unlisted_recipient above all RBL checks since there is no
>> benefit in checking RBLs if you are anyway going to reject them later
>> (if the recipient is not managed on your system).
>> I as well would not use zen.spamhaus.org (without a subscription) if
>> you have a high mail volume.
>
> Thank you Steve,
> I made as you suggested and now the MySQL threads still remains low
> even if reject_unlisted_recipient is on the top of the list.
> I also removed smahaus.org from the rbl check, I'm going to find out
> if it's conveninet subscribing to the service.
>

In addition, list.dsbl.org is dead and gone for some time now.
You are just adding a DNS lookup that will never return anything valuable.

RaSca

unread,
Jan 14, 2010, 3:19:05 AM1/14/10
to
Il giorno Mer 13 Gen 2010 18:52:58 CET, Brian Evans - Postfix List ha
scritto:
[...]

> In addition, list.dsbl.org is dead and gone for some time now.
> You are just adding a DNS lookup that will never return anything valuable.

Thanks everybody for the suggestions, I've got another problem now: this
night some mails were not dispatched directly to the maildir but those
remains queued. What i see from the logs is that the status is sent, but
the mail is not delivered to the maildir:

Jan 14 06:23:41 mail-1 postfix/smtp[3836]: C0F0620E04B:
to=<xxxx...@xxxxxxxxxxxx.com>, relay=127.0.0.1[127.0.0.1]:10025,
delay=0.11, delays=0.02/0/0.04/0.05, dsn=2.0.0, status=sent (250 2.0.0
Ok: queued as CE51C20E04A)

This morning after a few tests, i just restarted the postfix daemon, and
after a while mails arrived on the box.
Does this can depend from the proxy directive? Ho can i control this
postfix feature or check where things starts to go wrong (ok, quite
wrong since at the end every mail arrived)?

Thanks again,

Steve

unread,
Jan 14, 2010, 3:55:06 AM1/14/10
to

-------- Original-Nachricht --------
> Datum: Thu, 14 Jan 2010 09:19:05 +0100
> Von: RaSca <ra...@miamammausalinux.org>
> An: Postfix users <postfi...@postfix.org>
> Betreff: Re: Understanding Postfix and smtpd_recipient_restrictions priorities

> Il giorno Mer 13 Gen 2010 18:52:58 CET, Brian Evans - Postfix List ha
> scritto:
> [...]
> > In addition, list.dsbl.org is dead and gone for some time now.
> > You are just adding a DNS lookup that will never return anything
> valuable.
>
> Thanks everybody for the suggestions, I've got another problem now: this
> night some mails were not dispatched directly to the maildir but those
> remains queued. What i see from the logs is that the status is sent, but
> the mail is not delivered to the maildir:
>
> Jan 14 06:23:41 mail-1 postfix/smtp[3836]: C0F0620E04B:
> to=<xxxx...@xxxxxxxxxxxx.com>, relay=127.0.0.1[127.0.0.1]:10025,
> delay=0.11, delays=0.02/0/0.04/0.05, dsn=2.0.0, status=sent (250 2.0.0
> Ok: queued as CE51C20E04A)
>

You probably have a service listening on port 10025 (probably a greylisting service or such) and you forgot to start that service or the service crashed. Can you restart that service and then issue a "postsuper -r ALL"?


> This morning after a few tests, i just restarted the postfix daemon, and
> after a while mails arrived on the box.
> Does this can depend from the proxy directive? Ho can i control this
> postfix feature or check where things starts to go wrong (ok, quite
> wrong since at the end every mail arrived)?
>
> Thanks again,
>
> --
> RaSca

> Mia Mamma Usa Linux: Niente � impossibile da capire, se lo spieghi bene!
> ra...@miamammausalinux.org
> http://www.miamammausalinux.org

--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

RaSca

unread,
Jan 14, 2010, 4:07:38 AM1/14/10
to
Il giorno Gio 14 Gen 2010 09:55:06 CET, Steve ha scritto:
[...]
> You probably have a service listening on port 10025 (probably a greylisting service or such) and you forgot to start that service or the service crashed. Can you restart that service and then issue a "postsuper -r ALL"?
[...]

Of course I have it. It's the clamsmtp daemon:

tcp 0 0 127.0.0.1:10025 0.0.0.0:*
LISTEN 4579/clamsmtpd

But it was not crashed. The only thing I've done to turn things on again
was to restart the postfix daemon, without restarting anything else.
For making myself more clear, I try to explain with more details my
architecture. Postfix is configured for passing the mails to the
clamsmtp daemon.

main.cf:

content_filter = scan:127.0.0.1:10025
receive_override_options = no_address_mappings
unknown_local_recipient_reject_code = 450

master.cf:

scan unix - - n - 16 smtp
-o smtp_send_xforward_command=yes

127.0.0.1:10026 inet n - n - 16 smtpd
-o content_filter=
-o
receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks_style=host
-o smtpd_authorized_xforward_hosts=127.0.0.0/8

Obviously clamsmtp is listening on the 10025.

As you say, something in the mail chain was broken, but I can extract
from the logs which component is. Have you any suggestion?

Thank you for your precious support!

P.S.: What the "postsuper -r ALL" command do?

--
RaSca
Mia Mamma Usa Linux: Niente è impossibile da capire, se lo spieghi bene!
ra...@miamammausalinux.org
http://www.miamammausalinux.org

0 new messages