On 10/28/20 2:38 PM, Wietse Venema wrote:
One possible way out is to skip the Postfix sendmail command, and
to use a "mini sendmail" program that submits mail via SMTP.
adding an msmtp sender as the VirusAction script in clamav milter, though a bit
of 'extra', certainly is the simplest.
easy
On 10/28/20 2:38 PM, Wietse Venema wrote:
One possible way out is to skip the Postfix sendmail command, and
to use a "mini sendmail" program that submits mail via SMTP.
i've typically got msmtp rattling around.
Obviously that will fail when Postfix is down.
noted.
not ideal, but not
PGNet Dev:
> my clamav-milter.conf includes
>
> VirusAction /usr/local/etc/clamav/scripts/virus-alert.sh
>
> where that script _does_ invoke sendmail.
>
> found this process
>
> ps ax | grep virus
> 15670 ?S 0:00 /bin/bash
>
On 10/28/20 11:36 AM, PGNet Dev wrote:
On 10/28/20 11:30 AM, Viktor Dukhovni wrote:
You might start with:
# grep -r NoNewPrivileges /etc/systemd
i couldn't find any direct, relevant postdrop/maildrop, or NoNewPrivileges,
references i chased sendmail usage instances instead.
i've
On 10/28/20 11:30 AM, Viktor Dukhovni wrote:
You might start with:
# grep -r NoNewPrivileges /etc/systemd
and all other directories with systemd unit files.
yup. already done.
nothing --other than the now "=false" (need to double check if that's the same
as _removing_ it ) in
On Wed, Oct 28, 2020 at 11:22:55AM -0700, PGNet Dev wrote:
> On 10/28/20 10:32 AM, Viktor Dukhovni wrote:
> > Indeed a process with "no_new_privs" will not be able to run sendmail(1)
> > to submit new email.
>
> noted.
>
> that said, this _just_ reappeared here,
>
>postfix/postdrop[15673]:
On 10/28/20 10:32 AM, Viktor Dukhovni wrote:
Indeed a process with "no_new_privs" will not be able to run sendmail(1)
to submit new email.
noted.
that said, this _just_ reappeared here,
postfix/postdrop[15673]: warning: mail_queue_enter: create file
maildrop/678088.15673: Permission
On Wed, Oct 28, 2020 at 06:19:10PM +0100, Bastian Blank wrote:
> > Barring interference from SELinux or AppArmour, ... this should not
> > happen unless file permissions change.
>
> Maybe this was true ten years ago, but it is not longer. The OP even
> mentioned something called "no new
Hi Viktor
On Wed, Oct 28, 2020 at 01:00:35PM -0400, Viktor Dukhovni wrote:
> On Wed, Oct 28, 2020 at 09:01:38AM -0700, PGNet Dev wrote:
> > Oct 28 15:02:40 svr019 postfix/postdrop[64624]: warning:
> > mail_queue_enter: create file maildrop/553726.64624: Permission denied
> > Oct 28
On Wed, Oct 28, 2020 at 10:13:23AM -0700, PGNet Dev wrote:
> > For reference, on my system:
> >
> > $ postconf setgid_group
> > setgid_group = maildrop
> > $ ls -ld /var/spool/postfix/maildrop
> > drwx-wx--- 2 postfix maildrop 2 Oct 28 12:52
> >
On 10/28/20 10:00 AM, Viktor Dukhovni wrote:
On Wed, Oct 28, 2020 at 09:01:38AM -0700, PGNet Dev wrote:
Oct 28 15:02:40 svr019 postfix/postdrop[64624]: warning:
mail_queue_enter: create file maildrop/553726.64624: Permission denied
Oct 28 15:02:45 svr019
On Wed, Oct 28, 2020 at 09:01:38AM -0700, PGNet Dev wrote:
> Oct 28 15:02:40 svr019 postfix/postdrop[64624]: warning:
> mail_queue_enter: create file maildrop/553726.64624: Permission denied
> Oct 28 15:02:45 svr019 postfix/postdrop[32688]: warning:
> mail_queue_enter: create file
on a new, from-distro-pkgs install of Postfix, i've noted an intermittent perms
problem
it'll run just fine for quite awhile, then I start seeing a steady stream of
...
Oct 28 15:02:40 svr019 postfix/postdrop[64624]: warning:
mail_queue_enter: create file
13 matches
Mail list logo
