I just installed a Postfix server and enabled DNSBL-based rejection with
smtpd_recipient_restrictions = check_recipient_access
hash:/usr/local/etc/postfix/conf/bozos, reject_non_fqdn_recipient,
permit_sasl_authenticated, permit_mynetworks,
reject_unauth_destination,
On Fri, Apr 27, 2012 at 08:55:15AM -0700, kar...@mailcan.com wrote:
I just installed a Postfix server and enabled DNSBL-based rejection with
[..]
In every case though there are multiple connections made with multiple
rejects. For example
[..]
In the end it's getting blocked, and that's
On Fri, Apr 27, 2012, at 06:09 PM, Dennis Guhl wrote:
The caching is done in your local resolver, not in postfix.
Ok, I can check that and make sure that those results are being returned
from my LAN DNS server's cache.
Is there any way to prevent Postfix from making those repeated DNS
checks,
On 27 Apr 2012, at 16:55, kar...@mailcan.com wrote:
In the end it's getting blocked, and that's what I want. But, if I
understand how this works, every one of those rejects is a DNS check
to
spamhaus, and some postfix load on my server.
Can I somehow configure to be more efficient about
On Fri, Apr 27, 2012 at 09:20:21AM -0700, kar...@mailcan.com wrote:
On Fri, Apr 27, 2012, at 06:09 PM, Dennis Guhl wrote:
The caching is done in your local resolver, not in postfix.
[..]
Is there any way to prevent Postfix from making those repeated DNS
checks, regardless of whether it's
On Fri, Apr 27, 2012, at 05:23 PM, Jim Reid wrote:
The info will already be cached at your local DNS server. So you've
snip.
Nicely explained.
My advice is to leave this alone. It's already working at maximum
efficiency pretty much straight out of the box and there are no
meaningful
On 27 Apr 2012, at 17:20, kar...@mailcan.com wrote:
Is there any way to prevent Postfix from making those repeated DNS
checks, regardless of whether it's externally to Spamhaus' servers, or
to a locally cached DNS result?
No. Well you could but it would be futile make-work that adds needless
On Fri, Apr 27, 2012, at 05:32 PM, Jim Reid wrote:
This is beginning to smell very
much like something the DNS already provides for free.
If that auto-expiry hash table functionality is not already build into
Postfix (which would be kind of nice to have for other things to; may
look into it
On Fri, Apr 27, 2012 at 08:55:15AM -0700, kar...@mailcan.com wrote:
smtpd_recipient_restrictions =
check_recipient_access hash:/usr/local/etc/postfix/conf/bozos
Remove or at least move _after_ reject_unauth_destination. This is prone
for open relay.
reject_non_fqdn_recipient
Why?
Please respond to the list as well, thanks.
On Fri, Apr 27, 2012, at 05:38 PM, Jim Reid wrote:
Er, think about this. How will postscreen do those RBL checks?
Clearly, as I said I'm still reading, I'm not sure.
It will do DNS lookups!
Right. The 1st time. And if it *was* capable of storing
On Fri, Apr 27, 2012, at 06:43 PM, Bastian Blank wrote:
On Fri, Apr 27, 2012 at 08:55:15AM -0700, kar...@mailcan.com wrote:
smtpd_recipient_restrictions =
check_recipient_access hash:/usr/local/etc/postfix/conf/bozos
Remove or at least move _after_ reject_unauth_destination. This
kar...@mailcan.com:
On Fri, Apr 27, 2012, at 05:23 PM, Jim Reid wrote:
The info will already be cached at your local DNS server. So you've
snip.
Nicely explained.
My advice is to leave this alone. It's already working at maximum
efficiency pretty much straight out of the box
On Fri, Apr 27, 2012, at 01:47 PM, Wietse Venema wrote:
I'd still think that a local check by Postfix to an 'auto-expiring hash
table' (unclear so far it that can be done) to which the 'bad' address
Each Postfix SMTP server caches its own DNSBL lookup results. Those
results are not shared
On Fri, Apr 27, 2012 at 10:58:32AM -0700, kar...@mailcan.com wrote:
On Fri, Apr 27, 2012, at 01:47 PM, Wietse Venema wrote:
I'd still think that a local check by Postfix to an 'auto-expiring hash
table' (unclear so far it that can be done) to which the 'bad' address
Each Postfix SMTP
On 2012-04-27 kar...@mailcan.com wrote:
On Fri, Apr 27, 2012, at 06:43 PM, Bastian Blank wrote:
On Fri, Apr 27, 2012 at 08:55:15AM -0700, kar...@mailcan.com wrote:
reject_non_fqdn_recipient
Why?
Because countless documentation examples suggest it, including in The
Postfix Book.
For
kar...@mailcan.com:
On Fri, Apr 27, 2012, at 01:47 PM, Wietse Venema wrote:
I'd still think that a local check by Postfix to an 'auto-expiring hash
table' (unclear so far it that can be done) to which the 'bad' address
Each Postfix SMTP server caches its own DNSBL lookup results.
On Fri, Apr 27, 2012 at 08:16:47PM +0200, Ansgar Wiechers wrote:
On 2012-04-27 kar...@mailcan.com wrote:
On Fri, Apr 27, 2012, at 06:43 PM, Bastian Blank wrote:
On Fri, Apr 27, 2012 at 08:55:15AM -0700, kar...@mailcan.com wrote:
reject_non_fqdn_recipient
Why?
Because countless
On Fri, Apr 27, 2012, at 08:16 PM, Ansgar Wiechers wrote:
reject_non_fqdn_recipient
For my personal mail server I use this rule, too. However, you need to
be aware that it might reject some legit mail (e.g. from mail servers
configured by stupid, but valid, customers), hence the rule
On Fri, Apr 27, 2012, at 02:20 PM, Wietse Venema wrote:
kar...@mailcan.com:
Each Postfix SMTP server process is reused.
http://www.postfix.org/postconf.5.html#max_use
http://www.postfix.org/postconf.5.html#max_idle
That answers my question. Both of the defaults seem to fit nicely
enough
On Fri, Apr 27, 2012, at 05:32 PM, Jim Reid wrote:
On 27 Apr 2012, at 17:20, kar...@mailcan.com wrote:
Is there any way to prevent Postfix from making those repeated DNS
checks, regardless of whether it's externally to Spamhaus' servers, or
to a locally cached DNS result?
No. Well you
Den 2012-04-27 17:55, kar...@mailcan.com skrev:
reject_unauth_destination, reject_unlisted_recipient,
reject_unlisted_recipient is not needed AFTER reject_unauth_destination
On Fri, Apr 27, 2012, at 08:54 PM, Bron Gondwana wrote:
Just as an interesting point from a fairly large site (fastmail.fm) we
do something very like that. We run a standalone daemon, and we keep
a bad list of IPs who get dumped immediately without even a DNS lookup.
One of our patches to
kar...@mailcan.com:
On Fri, Apr 27, 2012, at 08:54 PM, Bron Gondwana wrote:
Just as an interesting point from a fairly large site (fastmail.fm) we
do something very like that. We run a standalone daemon, and we keep
a bad list of IPs who get dumped immediately without even a DNS
On Fri, Apr 27, 2012 at 12:02:05PM -0700, kar...@mailcan.com wrote:
On Fri, Apr 27, 2012, at 08:54 PM, Bron Gondwana wrote:
Just as an interesting point from a fairly large site
(fastmail.fm) we do something very like that. We run a
standalone daemon, and we keep a bad list of IPs who
On 4/27/2012 1:54 PM, Bron Gondwana wrote:
Just as an interesting point from a fairly large site (fastmail.fm) we
do something very like that. We run a standalone daemon, and we keep
a bad list of IPs who get dumped immediately without even a DNS lookup.
One of our patches to postfix
On Fri, Apr 27, 2012, at 03:12 PM, Wietse Venema wrote:
For small sites, postscreen has an up-front blacklist that kicks
off clients before wasting resources on them.
Although I was warned off postscreen in an earlier post being 'heavier'
than the checks against locally cached DNS, your
On 4/27/2012 2:12 PM, /dev/rob0 wrote:
Postfix is going to do a reverse DNS lookup of any connecting client,
followed by a forward lookup of the PTR name received.
These are done in the postfix/smtpd client.
This is fine
for most sites. Small sites can save some of this using postscreen,
On 4/27/2012 2:17 PM, kar...@mailcan.com wrote:
On Fri, Apr 27, 2012, at 03:12 PM, Wietse Venema wrote:
For small sites, postscreen has an up-front blacklist that kicks
off clients before wasting resources on them.
Although I was warned off postscreen in an earlier post being 'heavier'
28 matches
Mail list logo
