Yes indeed, I had expected postsuper -h ALL would put the system on hold
for all messages, especially future messages.
Thank you for the clarification of the postsuper man page. Much
appreciated.
Am Do., 18. Okt. 2018 um 20:44 Uhr schrieb Viktor Dukhovni <
postfix-us...@dukhovni.org>:
>
>
> > On
H?kon Alstadheim:
> I have a rather convoluted multi-instance setup that mostly works to my
> liking, with spam-filters, hand-off to mailman, dkim-signing and
> whatnot. One problem is that mis-typed outgoing addresses (host part)
> from my local, authenticated users end up deferred (450) and not
> On Oct 21, 2018, at 5:14 PM, Peer Heinlein
> wrote:
>
> If a client connects to smtpd and then breaks the connection because
> there's only STARTTLS or AUTH ONLY we have those remaining smtpd
> processes -- which makes the server looking busy, while he isn't.
>
> If there's really a long
Am 20.10.2018 um 19:06 schrieb Wietse Venema:
Hi,
>> If a client disconnects very early, the smtpd is still "unused" and
>> remains in server memory, waiting for the next connection.
>
> The Postfix behavior has nothing to do with the duration of an SMTP
> session. It is determined by the
Sorry folks, I'm not entirely there today. Receiving MX may of course be
temporarily gone from DNS, so 450 it is. Pleas allow this thread to
disappear into oblivion. :-)
Den 21. okt. 2018 15:47, skrev Håkon Alstadheim:
> I have a rather convoluted multi-instance setup that mostly works to my
>
I have a rather convoluted multi-instance setup that mostly works to my
liking, with spam-filters, hand-off to mailman, dkim-signing and
whatnot. One problem is that mis-typed outgoing addresses (host part)
from my local, authenticated users end up deferred (450) and not bounced
back to the
gaurav.parashar:
I had installed postfix in Ubuntu 16.04 and it was working seamlessly. Some
time back I upgraded it to Ubuntu 18.04 and suddenly emails stop coming to
my inbox. It gave me this error:
postfix/postdrop[27466]: warning: mail_queue_enter: create file
maildrop/675261.27466:
we're monitoring the amount of active smtpd processes to make sure, that
we do not reach the max-proc limit from master.cf.
The number I found most useful to indicate something was going wrong
is the number of messages in the queue. For the servers I manage,
normally that number would be
On 10/20/2018 7:24 AM, Peer Heinlein wrote:
we're monitoring the amount of active smtpd processes to make sure, that
we do not reach the max-proc limit from master.cf.
If a client disconnects very early, the smtpd is still "unused" and
remains in server memory, waiting for the next connection.
