Re: opendkim - permission issue?

2022-06-26 Thread Maurizio Caloro
On 27.06.2022 00:24, Wietse Venema wrote: Maurizio Caloro: setup also opendkim and will appear now the error " *key data is not secure: / is writeable and owned by uid 110 which is not the executing uid (115)* *or the superuser*" it's seem that i have permission issue? Look at the output

Re: Rejecting mail from localhost.localdomain

2022-06-26 Thread Viktor Dukhovni
On Sun, Jun 26, 2022 at 10:23:26PM -0400, Alex wrote: > Is it safe to add something like this to my helo_checks.pcre: > > check_helo_access pcre:$config_directory/helo_checks.pcre > /*.localdomain/ REJECT This is a "glob" pattern, it is not a valid PCRE pattern. It also

Rejecting mail from localhost.localdomain

2022-06-26 Thread Alex
Hi, I was surprised to see I received an email with localhost.localdomain as the envelope sender. It was a legitimate email, but not from my mail host. Jun 16 16:15:29 armor policyd-spf[55040]: prepend Received-SPF: None (mailfrom) identity=mailfrom; client-ip=50.210.225.242;

Re: opendkim - permission issue?

2022-06-26 Thread Wietse Venema
Maurizio Caloro: > > setup also opendkim and will appear now the error "key data is not > secure: / is writeable and owned by uid 110 which is not the executing > uid (115)" > it's seem that i have permission issue? Look at the output from: ls -ld / Wietse

opendkim - permission issue?

2022-06-26 Thread Maurizio Caloro
setup also opendkim and will appear now the error "key data is not secure: / is writeable and owned by uid 110 which is not the executing uid (115)" it's seem that i have permission issue? # opendkim -V     opendkim: OpenDKIM Filter v2.11.0     Compiled with OpenSSL 1.1.1n  15 Mar 2022

Re: Catch-all that pipes to script

2022-06-26 Thread Jaroslaw Rafa
Dnia 26.06.2022 o godz. 13:09:24 Wietse Venema pisze: > > Can't this be even simpler? Does it really need to define a dedicated > > transport and entry in master.cf? > > Can't l...@example.com be just an alias that pipes mail to the "mailbot" > > script directly? > > Then, the address could be

Re: Catch-all that pipes to script

2022-06-26 Thread Wietse Venema
Jaroslaw Rafa: > Dnia 25.06.2022 o godz. 21:30:35 Viktor Dukhovni pisze: > > But you don't need a catchall for the problem at hand. Why not just > > > > main.cf: > > mailbot_destination_recipient_limit = 1 > > > > virtual: > > l...@example.com luc@hidden.invalid > >

Re: Catch-all that pipes to script

2022-06-26 Thread Jaroslaw Rafa
Dnia 25.06.2022 o godz. 21:30:35 Viktor Dukhovni pisze: > But you don't need a catchall for the problem at hand. Why not just > > main.cf: > mailbot_destination_recipient_limit = 1 > > virtual: > l...@example.com luc@hidden.invalid > > transport: >

Re: parameter append syntax (was: milter_header_checks, pcre, chroot)

2022-06-26 Thread raf
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

Re: Legacy recipient restriction using the "%" character

2022-06-26 Thread Wietse Venema
Ralph Seichter: > Hello list. > > I am currently pondering the continued usefulness of the restriction > > smtpd_recipient_restrictions = > ... > check_recipient_access pcre:/etc/postfix/recipient_access > ... > > with the content of /etc/postfix/recipient_access (1) being: > >

Legacy recipient restriction using the "%" character

2022-06-26 Thread Ralph Seichter
Hello list. I am currently pondering the continued usefulness of the restriction smtpd_recipient_restrictions = ... check_recipient_access pcre:/etc/postfix/recipient_access ... with the content of /etc/postfix/recipient_access (1) being: /[@!%].*[@!%]/ REJECT As per RFC 5322,

Re: parameter append syntax (was: milter_header_checks, pcre, chroot)

2022-06-26 Thread Wietse Venema
raf: > Also, is .= the best notation? Would += be better? https://marc.info/?l=postfix-users=164779562215790=2 Wietse