On Sun, Jun 26, 2022 at 07:45:47AM -0400, Wietse Venema
wrote:
> raf:
> > Also, is .= the best notation? Would += be better?
>
> https://marc.info/?l=postfix-users=164779562215790=2
>
> Wietse
Of course.
cheers,
raf
raf:
> Also, is .= the best notation? Would += be better?
https://marc.info/?l=postfix-users=164779562215790=2
Wietse
On Sat, Jun 25, 2022 at 09:08:30PM -0400, Wietse Venema
wrote:
> raf:
> > If .= can reliably distinguish between being applied to
> > a list or scalar parameter, maybe it could automatically
> > include a leading space when adding to lists.
>
> Unfortunately, the main.cf parser does not know
raf:
> If .= can reliably distinguish between being applied to
> a list or scalar parameter, maybe it could automatically
> include a leading space when adding to lists.
Unfortunately, the main.cf parser does not know if a parameter value
is used as a list such as
export_environment = TZ
On Sat, Jun 25, 2022 at 11:07:20AM -0400, Wietse Venema wrote:
> It can be fixed by requiring a comma when appending to a list:
>
> export_environment .= , { NAME = value }
Indeed something like this would have to be the main.cf syntax, unless
there are instead two related append operators:
On Sat, Jun 25, 2022 at 11:07:20AM -0400, Wietse Venema
wrote:
> Wietse:
> >I'm looking into adding "name .= value" support but this is tricky
> >because it has to work not only in main.cf but also in master.cf
> >(-o name.=value).
>
> That idea originated in the context op adding an 'extra'
Wietse:
>I'm looking into adding "name .= value" support but this is tricky
>because it has to work not only in main.cf but also in master.cf
>(-o name.=value).
That idea originated in the context op adding an 'extra' to the
default value of export_environment, or addind map that I forgot
to
Hello,
sorry to revive old thread, but I came to another case where proposed change
would be beneficial.
Jesper Dybdal:
Thanks. As far as I can see, I need to add
proxy:regexp:/etc/postfix/regexp_milter_header_checks
to proxy_read_maps. But proxy_read_maps has a long default value -
On 2022-04-14 16:58, Matus UHLAR - fantomas wrote:
OTOH, rejecting DMARC failures with policy reject should be not a
problem, since there's just a few of them.
since many maillist take ownerships its not a problem at all :)
but its more a fail if opendkim reject, i will let it up to the
On 2022-03-19 17:49, Matus UHLAR - fantomas wrote:
this should be fixable by using proxymap, better than disabling chroot
http://www.postfix.org/proxymap.8.html
On 20.03.22 17:29, Jesper Dybdal wrote:
Thanks. As far as I can see, I need to add
On 22/03/2022 16:40, Benny Pedersen wrote:
OpenDMARC's internal SPF handling will be removed
in a future version.
Modern versions of openDMARC can and should be built with dependency on
libspf2, so would never use the very old internal spf code, and instead
use libspf2
On 2022-03-22 12:45, Matus UHLAR - fantomas wrote:
NOTE: OpenDMARC's internal SPF handling will be removed
in a future version.
and although I don't recall the exact details, I seem to remember
there was a security exploit that could be prevented by
getting OpenDMARC to
However, opendmarc milter requires those Authentication-Results
headers for SPF and DKIM to be already present. so you need
spf/dkim milter(s) before opendmarc.
On 19/03/22 01:46, Jesper Dybdal wrote:
I use Amavis to generate and verify DKIM signatures, and
policyd-spf-python to perform SPF
On 19/03/22 01:46, Jesper Dybdal wrote:
However, opendmarc milter requires those Authentication-Results
headers for SPF and DKIM to be already present. so you need spf/dkim
milter(s) before opendmarc.
I use Amavis to generate and verify DKIM signatures, and
policyd-spf-python to perform SPF
Wietse Venema:
> Jesper Dybdal:
> > On 2022-03-19 17:49, Matus UHLAR - fantomas wrote:
> > > this should be fixable by using proxymap, better than disabling chroot
> > > http://www.postfix.org/proxymap.8.html
> > Thanks. As far as I can see, I need to add
> >
Jesper Dybdal:
> On 2022-03-19 17:49, Matus UHLAR - fantomas wrote:
> > this should be fixable by using proxymap, better than disabling chroot
> > http://www.postfix.org/proxymap.8.html
> Thanks. As far as I can see, I need to add
> proxy:regexp:/etc/postfix/regexp_milter_header_checks
> to
On 2022-03-19 17:49, Matus UHLAR - fantomas wrote:
this should be fixable by using proxymap, better than disabling chroot
http://www.postfix.org/proxymap.8.html
Thanks. As far as I can see, I need to add
proxy:regexp:/etc/postfix/regexp_milter_header_checks
to proxy_read_maps. But
Wietse Venema:
> Viktor Dukhovni:
> > > On 19 Mar 2022, at 5:31 pm, Wietse Venema wrote:
> > >
> > > The cleanup server initializes Milters lazily, because they are not
> > > always needed. In some cases an smtpd process decides if Miltering
> > > is needed (based on the smtpd_milters setting),
Viktor Dukhovni:
> > On 19 Mar 2022, at 5:31 pm, Wietse Venema wrote:
> >
> > The cleanup server initializes Milters lazily, because they are not
> > always needed. In some cases an smtpd process decides if Miltering
> > is needed (based on the smtpd_milters setting), and in some cases
> > the
> On 19 Mar 2022, at 5:31 pm, Wietse Venema wrote:
>
> The cleanup server initializes Milters lazily, because they are not
> always needed. In some cases an smtpd process decides if Miltering
> is needed (based on the smtpd_milters setting), and in some cases
> the cleanup server makes that
Viktor Dukhovni:
> > On 19 Mar 2022, at 12:49 pm, Matus UHLAR - fantomas
> > wrote:
> >
> > This should be fixable by using proxymap, better than disabling chroot
> > http://www.postfix.org/proxymap.8.html
>
> Postfix typically opens all tables before chroot.
> Not clear whether initialisation
> On 19 Mar 2022, at 12:49 pm, Matus UHLAR - fantomas wrote:
>
> This should be fixable by using proxymap, better than disabling chroot
> http://www.postfix.org/proxymap.8.html
Postfix typically opens all tables before chroot.
Not clear whether initialisation of milter_header_checks
after
On 2022-03-18 12:35, I wrote:
I run postfix 3.4.14 (Debian Buster) with Amavisd-new as a
pre-queue filter.
...
Mar 18 11:42:53 nuser postfix/cleanup[8931]: warning: unsupported
dictionary type: pcre (/usr/lib/postfix/postfix-pcre.so: No such
file or directory)
Mar 18 11:42:53 nuser
On 2022-03-18 12:35, I wrote:
I run postfix 3.4.14 (Debian Buster) with Amavisd-new as a pre-queue
filter.
...
Mar 18 11:42:53 nuser postfix/cleanup[8931]: warning: unsupported
dictionary type: pcre (/usr/lib/postfix/postfix-pcre.so: No such file
or directory)
Mar 18 11:42:53 nuser
On 18.03.22 12:35, Jesper Dybdal wrote:
I run postfix 3.4.14 (Debian Buster) with Amavisd-new as a
pre-queue filter.
I would now like to add DMARC validation, done by the opendmarc
milter in the after-Amavis smtpd instance.
This basically works: opendmarc inserts an
Just an FYI re: an alternative:
https://github.com/fastmail/authentication_milter
It's freely available AND used in commercial production by the Fastmail crew.
I switched to it a while ago, from a similar setup.
I use it in its smtpd mode -- and does a good/reliable job of providing an
On 2022-03-18 13:07, Matus UHLAR - fantomas wrote:
On 18.03.22 12:35, Jesper Dybdal wrote:
I run postfix 3.4.14 (Debian Buster) with Amavisd-new as a pre-queue
filter.
I would now like to add DMARC validation, done by the opendmarc
milter in the after-Amavis smtpd instance.
This
On 18.03.22 12:35, Jesper Dybdal wrote:
I run postfix 3.4.14 (Debian Buster) with Amavisd-new as a pre-queue
filter.
I would now like to add DMARC validation, done by the opendmarc milter
in the after-Amavis smtpd instance.
This basically works: opendmarc inserts an
I run postfix 3.4.14 (Debian Buster) with Amavisd-new as a pre-queue
filter.
I would now like to add DMARC validation, done by the opendmarc milter
in the after-Amavis smtpd instance.
This basically works: opendmarc inserts an "Authentication-Results" header.
I would now like to do
29 matches
Mail list logo
