On 01.09.2017 14:09, Matus UHLAR - fantomas wrote:
On 01.09.17 10:37, Admin Beckspaced wrote:
but let's say I do a fail2ban restart on one of the servers lots of
fail2ban notify emails will get send via the relayhost
resulting in the relayhost throttling down the other server
which is actuall
The docs mention not to use root or postfix for the "-u UID" option. Then
what user should it be? Is a new user to be created for that purpose?
Should that same user own the /var/db/dkim directory and files?
Thanks.
-Tom
Il 2017-09-01 22:57 Noel Jones ha scritto:
[..]
On the backup MX:
DO NOT list the domain in mydestination, virtual_alias_domains, or
mailbox_domains parameters. These list domains for local delivery.
You mean: do not list the domain of the *primary server* in
mydestination, virtual_alias_
Tom Browder:
> The docs mention not to use root or postfix for the "-u UID" option. Then
> what user should it be? Is a new user to be created for that purpose?
> Should that same user own the /var/db/dkim directory and files?
All my opendkim FILES are owned by root, in directories owned by
root,
On Sun, Sep 3, 2017 at 06:44 Wietse Venema wrote:
> Tom Browder:
> The docs mention not to use root or postfix for the "-u UID" option. Then
> > what user should it be? Is a new user to be created for that purpose?
> > Should that same user own the /var/db/dkim directory and files?
>
> All my op
Tom Browder:
> On Sun, Sep 3, 2017 at 06:44 Wietse Venema wrote:
>
> > Tom Browder:
>
> > The docs mention not to use root or postfix for the "-u UID" option. Then
> > > what user should it be? Is a new user to be created for that purpose?
> > > Should that same user own the /var/db/dkim directo
On 03 Sep 2017, at 12:38 PM, Tom Browder wrote:
> The docs mention not to use root or postfix for the "-u UID" option. Then
> what user should it be? Is a new user to be created for that purpose?
Yes.
> Should that same user own the /var/db/dkim directory and files?
No.
The idea is that open
fyi, if you prefer a dedicated user approach, just need to make sure you're
consistent,
groupdel opendkim
groupadd opendkim
useradd opendkim -g opendkim -G "" -s /bin/false -d /var/run/opendkim -M
usermod -a -G opendkim postfix
id opendkim
uid=5117(opendkim) gid=5117(opendkim) groups=5117(op
Just a small nit:
running opendkim as user opendkim in the systemd service file completely
defeats the ability of opendkim to drop privileges *after* reading the
private keys as root. I suspect most people aren't aware that having a
daemon start as root and drop privileges itself is a security fea
fwiw, from Arch wiki
https://wiki.archlinux.org/index.php/OpenDKIM
"The OpenDKIM daemon does not need to run as root at all (the configuration
suggested earlier will have OpenDKIM drop root privileges by itself, but
systemd can do this too and much earlier)."
cat /etc/systemd/system/opendkim.serv
haha I was going to mention the Arch Wiki - it also gives misleading
advice. Their improved setup has private keys owned by (and writable by!)
the same user that the daemon runs as. Hacked daemon -> private key
compromise.
The default service file installed by the Arch package runs as root, btw,
a
Of course, it can't actually b this simple. None of this applies if you use
a KeyTable:
Thus, keys referenced by the KeyTable must always be accessible for read by
the unprivileged user.
Those keys are read at first use, not when the daemon starts up. *sigh. I
knew there was something I was forg
On 3 September 2017 at 12:08, pgndev wrote:
...
Thanks for all the responses.
Does everyone agree with pgndev's detailed cookbook recipe?
-Tom
pgndev:
> fyi, if you prefer a dedicated user approach, just need to make sure you're
> consistent,
>
> groupdel opendkim
> groupadd opendkim
> useradd opendkim -g opendkim -G "" -s /bin/false -d /var/run/opendkim -M
> usermod -a -G opendkim postfix
This advice is incorrect. There is no need to
Tom Browder:
> On 3 September 2017 at 12:08, pgndev wrote:
> ...
>
> Thanks for all the responses.
>
> Does everyone agree with pgndev's detailed cookbook recipe?
No, that advice is incorrect.
1) Specify the opendkim '-u' option with an account that is not
used by anything else. Not postfix
On 9/3/2017 6:28 AM, Davide Marchi wrote:
> Il 2017-09-01 22:57 Noel Jones ha scritto:
> [..]
>>
>> On the backup MX:
>>
>>
>> DO NOT list the domain in mydestination, virtual_alias_domains, or
>> mailbox_domains parameters. These list domains for local delivery.
>
>
> You mean: do not list the
My simple list is working pretty good. I got the headers fixed per Gmail
(but no dkim yet) and mail to gmail addrees is NOT going to spam. The mail
to protonmail is still going to spam, but when I get dkim working I hope
that will fix that problem.
The only real problem I see is the sender addres
The info I posted earlier, about private keys read via a KeyTable - that
comes from the "FILE PERMISSIONS" section of the opendkim man page.
--
Harald
On Sun, Sep 3, 2017 at 13:56 Wietse Venema wrote:
> Tom Browder:
> > Does everyone agree with pgndev's detailed cookbook recipe?
>
> No, that advice is incorrect.
>
> 1) Specify the opendkim '-u' option with an account that is not
>used by anything else. Not postfix. Not . Not your person
On 09/03/2017 07:43 AM, Wietse Venema wrote:
> Tom Browder:
>> The docs mention not to use root or postfix for the "-u UID" option. Then
>> what user should it be? Is a new user to be created for that purpose?
>> Should that same user own the /var/db/dkim directory and files?
>
> All my opendkim F
20 matches
Mail list logo
