On Fri, 2019-02-15 at 20:42 +0100, Christopher R. Gabriel wrote:
> > > > Is the "delay" recorded in a typical Postfix log entry ?
> > > > Stolen from Postfix 2.3.19:
> > > > Postfix logs additional delay information as "delays=a/b/c/d"
> > > > where a=time before queue manager, including message
On Fri, 15 Feb 2019, 18:28 Wietse Venema Christopher R. Gabriel:
> > On Fri, 2019-02-15 at 09:35 -0700, angelo wrote:
> > > Hi Christopher,
> > > I'm on the opendkim list also and it does get little attention.
> >
> > Really? :)
> >
> > > Is the "delay" recorded in a typical Postfix log entry ?
>
On Friday, February 15, 2019 05:01:45 PM Christopher R. Gabriel wrote:
...
> The project seems a bit abandonware (no answers to bugs in years,
> repository almost stuck), and also recently orphaned by debian
> maintainer.
...
FYI, that was me. I orphaned it because I'm not using it anymore. As f
Christopher R. Gabriel:
> On Fri, 2019-02-15 at 09:35 -0700, angelo wrote:
> > Hi Christopher,
> > I'm on the opendkim list also and it does get little attention.
>
> Really? :)
>
> > Is the "delay" recorded in a typical Postfix log entry ?
> > Stolen from Postfix 2.3.19:
> > Postfix logs additi
On Fri, 2019-02-15 at 09:35 -0700, angelo wrote:
> Hi Christopher,
> I'm on the opendkim list also and it does get little attention.
Really? :)
> Is the "delay" recorded in a typical Postfix log entry ?
> Stolen from Postfix 2.3.19:
> Postfix logs additional delay information as "delays=a/b/c/d"
Hi Christopher,
I'm on the opendkim list also and it does get little attention.
Is the "delay" recorded in a typical Postfix log entry ?
Stolen from Postfix 2.3.19:
Postfix logs additional delay information as "delays=a/b/c/d"
where a=time before queue manager, including message transmission;
On Mon, 2019-01-14 at 12:42 +0100, Christopher R. Gabriel wrote:
> On Fri, 2019-01-04 at 19:56 +0100, Matus UHLAR - fantomas wrote:
> > On 04.01.19 15:23, Christopher R. Gabriel wrote:
> > > I have a generator server which injects (via smtp) into postfix,
> > > the
> > > actual sender, and when bur
On Fri, 2019-01-04 at 19:56 +0100, Matus UHLAR - fantomas wrote:
> On 04.01.19 15:23, Christopher R. Gabriel wrote:
> > I have a generator server which injects (via smtp) into postfix,
> > the
> > actual sender, and when burst of delivery happens, the receiving
> > postfix stuck before answering to
Christopher R. Gabriel skrev den 2019-01-04 15:23:
postfix01 data/spool are on tmpfs.
its unsafe to use tmpfs for spool dirs in postfix, tmpfs is okay only
for content-filters, not in generic postfix
On 04.01.19 15:23, Christopher R. Gabriel wrote:
I have a generator server which injects (via smtp) into postfix, the
actual sender, and when burst of delivery happens, the receiving
postfix stuck before answering to the generator, which causes the
generator queues to fill up.
Nov 30 09:11:58
On Fri, 2019-01-04 at 10:26 -0500, Viktor Dukhovni wrote:
> > On Jan 4, 2019, at 10:04 AM, Christopher R. Gabriel <
> > christopher.gabr...@gmail.com> wrote:
> >
> > > Or some tables you're using in cleanup are slow.
> >
> > I only have a header_checks table with 1 single rule to log a
> > speci
> On Jan 4, 2019, at 10:04 AM, Christopher R. Gabriel
> wrote:
>
>> Or some tables you're using in cleanup are slow.
>
> I only have a header_checks table with 1 single rule to log a specific
> header, and a transport map redis-based. Exactly the same configuration
> I have on postfix 2.x.
On Fri, 2019-01-04 at 09:49 -0500, Viktor Dukhovni wrote:
> > On Jan 4, 2019, at 9:23 AM, Christopher R. Gabriel <
> > christopher.gabr...@gmail.com> wrote:
> >
> > Nov 30 09:11:31 postfix01 postfix-main/smtpd[31800]: rec_put: type
> > E
> > len 0 data
> > Nov 30 09:11:31 postfix01 postfix-main/s
> On Jan 4, 2019, at 9:23 AM, Christopher R. Gabriel
> wrote:
>
> Nov 30 09:11:31 postfix01 postfix-main/smtpd[31800]: rec_put: type E
> len 0 data
> Nov 30 09:11:31 postfix01 postfix-main/smtpd[31800]:
> vstream_fflush_some: fd 18 flush 2433
> Nov 30 09:11:58 postfix01 postfix-main/smtpd[31800
Hi,
after upgrading to Debian 9 (thus Postfix 3.1.8) I'm experiecing an odd
behaviour, which causes slowness on all the infrastructure.
I have a generator server which injects (via smtp) into postfix, the
actual sender, and when burst of delivery happens, the receiving
postfix stuck before answer
15 matches
Mail list logo
