On Fri, Sep 26, 2014 at 02:54:28PM -0400, Wietse Venema wrote:
> Summary: check your main.cf for sleep commands.
D'oh! You are absolutely right, and sorry for not posting full postconf
-n earlier. I didn't even know that was possible, but there's a sleep 1
in smtpd_client_restrictions. I'm not su
On Fri, Sep 26, 2014 at 12:50:47PM +, Viktor Dukhovni wrote:
>
> Can you provide a bit more context from that trace. Replace the "..." with
> 20 or so more lines above the "flock(21, LOCK_UN)"
Yes, sorry for the delay; had to re-run it. Does this provide enough
context (from MAIL FROM):
10:
On Fri, Sep 26, 2014 at 07:18:27AM -0400, Wietse Venema wrote:
> Will Yardley:
> > On Thu, Sep 25, 2014 at 09:59:44PM -0700, Will Yardley wrote:
> > > I will try running strace on an smtpd process and see if that helps
> > > identify anything.
>
> Is the de
On Thu, Sep 25, 2014 at 11:27:29PM -0700, Will Yardley wrote:
> $fork_delay wouldn't affect this here, would it (it's set to 1s, but
> can't be set lower anyway)? I re-tried setting in_flow_delay and did a
> postfix reload, but that didn't change an
On Thu, Sep 25, 2014 at 09:59:44PM -0700, Will Yardley wrote:
> I will try running strace on an smtpd process and see if that helps
> identify anything.
Notice the nanosleep() call here, and the jump from 23:17:21.642640 to
23:17:22.642808 -- exactly a second.
23:17:21.608881 read(9, "
On Fri, Sep 26, 2014 at 12:59:58AM +, Viktor Dukhovni wrote:
> On Thu, Sep 25, 2014 at 05:34:46PM -0700, Will Yardley wrote:
>
> > The new systems are faster hardware, and faster disks, however, I notice
> > a very slight delay (maybe 1s) on the newer system a
We upgraded recently from 2.3.3 (RHEL5 stock Postfix) to 2.6.6 (RHEL6
stock Postfix). The settings, including $smtpd_sender_restrictions,
$smtpd_recipient_restrictions, and the ldap lookup maps (as well as the
backend LDAP servers) are the same.
The new systems are faster hardware, and faster dis
On Sun, Sep 14, 2014 at 11:42:24PM -0700, Will Yardley wrote:
> On Mon, Sep 15, 2014 at 08:29:47AM +0200, Patrick Ben Koetter wrote:
> >
> > A good way to check if this bug applies to your case is to "cat
> > /proc/mounts | grep unbound". As you can see there are se
On Mon, Sep 15, 2014 at 08:29:47AM +0200, Patrick Ben Koetter wrote:
>
> A good way to check if this bug applies to your case is to "cat /proc/mounts |
> grep unbound". As you can see there are several mounts in place in my example:
I don't see any of these at the present, but will look if / when
On Mon, Sep 15, 2014 at 04:54:11AM +, Viktor Dukhovni wrote:
> * Your DNS resolution is not functioning, which could also
> explain slow login, but in this case, you'd generally max
> out the smtpd(8) process limit.
Yes, this one occurred to me too, but I did test that specific
I've had Postfix seemingly stop responding 3 times on 2 systems over the
weekend. In all cases, the system is accessible, but logging in is
sluggish, however, load, iowait, memory usage, etc. all appear perfectly
normal. Postfix doesn't log any unusual errors / warnings / etc., but
simply seems to
On Fri, Jul 25, 2014 at 05:22:58PM -0400, Wietse Venema wrote:
> Will Yardley:
> > Ah, but in my case, I am using '.domain.tld' vs. 'domain.tld', so I
> > guess my original question really was, does .domain.tld match subdomains
> > for $mynetworks /
On Fri, Jul 25, 2014 at 10:09:08AM -0400, Wietse Venema wrote:
> Will Yardley:
> > > Actually, behavior depends on the parent_domain_matches_subdomains
> > > setting.
> So the present behavior is as if smtpd_client_event_limit_exceptions
> is not listed in parent_do
> Actually, behavior depends on the parent_domain_matches_subdomains
> setting. The default setting includes mynetworks, meaning that
> example.com will match host.example.com by default. With mynetworks
> removed from from parent_domain_matches_subdomains, .example.com
> will match host.example.c
On Mon, Jul 21, 2014 at 04:42:57PM -0500, Noel Jones wrote:
> This isn't an access map, and doesn't have the network notation
> searches built into access maps. See the docs on mynetworks for the
> syntax supported here:
> http://www.postfix.org/postconf.5.html#mynetworks
>
> It might be easiest t
On Wed, Jul 23, 2014 at 10:51:41AM -0500, Noel Jones wrote:
> > and then have
> > recommended =
>
> Yes, that should work as expected.
This seemed to work as expected in my tests on 2.6.x. However, on 2.3.3,
I get:
postfix/smtpd[5673]: fatal: restriction class `recommended' needs a definition
Thanks so much for the helpful response - just wanted to make sure I was
heading in the right direction, and this was exactly what I needed.
On Wed, Jul 23, 2014 at 10:51:41AM -0500, Noel Jones wrote:
> > My thought was that maybe I should do something like this instead:
> >
> > reject_non
I'm wondering if someone can help me make sure I get the order right for
some recipient classes. I had hoped to just phase these out in favor of
a more unified system
The *intent* was to have the recommended class behave the same as a user
without the attribute set to 'recommended'.
Right now, th
On Mon, Jul 21, 2014 at 04:42:57PM -0500, Noel Jones wrote:
>
> It might be easiest to use a flat file, which allows both names and
> networks, rather than a hash: or cidr: table.
Thanks - I think this is how it was setup at one point, and that
explains why.
w
We have:
smtpd_client_event_limit_exceptions =
192.168.0.0/16,127.0.0.1,cidr:/etc/postfix/config/white_list,hash:/etc/postfix/config/white_list_internal_servers,hash:/etc/postfix/config/anvil_whitelist
configured for Anvil. The last file is for rate-limiting exemptions
only, whereas the other 2 a
On Thu, Nov 29, 2012 at 01:26:34PM -0500, Wietse Venema wrote:
> Ed Flecko:
> > gpg --verify postfix-2.9.4.tar.gz.sig postfix-2.9.4.tar.gz
> > gpg: no valid OpenPGP data found.
>
> It's an RSA key.
On Thu, Nov 29, 2012 at 10:35:38AM -0800, Ed Flecko wrote:
>
> So, I guess, gnupg won't verify an
On Wed, Nov 28, 2012 at 04:02:57PM -0600, Noel Jones wrote:
> On 11/28/2012 1:17 PM, Will Yardley wrote:
> > I'm having a problem where messages are accepted but then seem to
> > generate a mail forwarding loop. It seems to happen a lot with mail
> > from a particular
[Apologies in advance for the less than complete information below;
hoping someone may have an idea of what's happening anyway]
I'm having a problem where messages are accepted but then seem to
generate a mail forwarding loop. It seems to happen a lot with mail from
a particular spammer.
The To:
23 matches
Mail list logo
