Re: config check

On 09/12/2019 20:54, Viktor Dukhovni wrote: On Dec 9, 2019, at 3:38 PM, LuKreme wrote: The configuration as posted, and specifically the line I quoted directly above my comment, allowed unauthenticated traffic from anything on the LAN. This means random printers, IOT devices, android

Re: config check

On 12/9/19 2:29 PM, @lbutlr wrote: On 09 Dec 2019, at 13:54, Viktor Dukhovni wrote: On Dec 9, 2019, at 3:38 PM, LuKreme wrote: The configuration as posted, and specifically the line I quoted directly above my comment, allowed unauthenticated traffic from anything on the LAN. This means

Re: config check

On 09 Dec 2019, at 13:54, Viktor Dukhovni wrote: > On Dec 9, 2019, at 3:38 PM, LuKreme wrote: >> The configuration as posted, and specifically the line I quoted directly >> above my comment, allowed unauthenticated traffic from anything on the LAN. >> This means random printers, IOT devices,

Re: RES_DEFNAMES and RES_DNSRCH not working with smtp_host_lookup=dns

On Mon, Dec 09, 2019 at 03:48:50PM -0500, Jaroslav Skarvada wrote: > it seems the resolver was rewritten (probably in postfix 3.1.x), but > it seems it now uses res_query instead of the res_search which results > in RES_DEFNAMES and RES_DNSRCH not supported with smtp_host_lookup=dns, > example: >

Re: config check

> On Dec 9, 2019, at 3:38 PM, LuKreme wrote: > > The configuration as posted, and specifically the line I quoted directly > above my comment, allowed unauthenticated traffic from anything on the LAN. > This means random printers, IOT devices, android phones, etc were allowed to > send mail

RES_DEFNAMES and RES_DNSRCH not working with smtp_host_lookup=dns

Hi, it seems the resolver was rewritten (probably in postfix 3.1.x), but it seems it now uses res_query instead of the res_search which results in RES_DEFNAMES and RES_DNSRCH not supported with smtp_host_lookup=dns, example: # postconf -e "relayhost = [smtp]" # postconf -e smtp_host_lookup=dns #

Re: config check

On Dec 9, 2019, at 12:58, Viktor Dukhovni wrote > Please don't impute false crises. There is no "security hole", though the > configuration is a mess, unauthenticated loopback (and other "mynetworks") > traffic is normal. The configuration as posted, and specifically the line I quoted directly

Re: config check

On Mon, Dec 09, 2019 at 01:02:23PM +, Felix Rubio wrote: > Thank you very much for your answer. I really appreciate the time you > took to go through it. The reason for having the tls/auth parameters > configured was, actually, a requirement I did not write (sorry for that, > I wrote

Re: config check

On Mon, Dec 09, 2019 at 06:15:16AM -0700, @lbutlr wrote: > > On 09 Dec 2019, at 00:17, Felix Rubio wrote: > > > > Allow unencrypted/unauthenticated users to submit mail from local > > (127.0.0.x) connections Whether or not one is willing (or needs) to allow unauthenticated connections from

Re: config check

Yes, because those ranges belonged to virtual interfaces I previously had on my machine. I removed that already. Thank you for the comment, though! On 2019-12-09 13:15, @lbutlr wrote: On 09 Dec 2019, at 00:17, Felix Rubio wrote: Allow unencrypted/unauthenticated users to submit mail from

Re: Postfix header_checks not working: Invalid preceding regular expression

Il 09/12/19 16:10, Wietse Venema ha scritto: Simone Marchioni: Any idea why with postmap -q it shows REJECT but in real usage it doesn't work? What happens when you do $ LANG=C postmap -q Hint: Postfix daemons run in the C locale, and you may have some UTF8 in your pattern.

Re: Postfix header_checks not working: Invalid preceding regular expression

Simone Marchioni: > Any idea why with postmap -q it shows REJECT but in real usage it > doesn't work? What happens when you do $ LANG=C postmap -q Hint: Postfix daemons run in the C locale, and you may have some UTF8 in your pattern. Wietse

Re: Postfix header_checks not working: Invalid preceding regular expression

Il 09/12/19 15:34, Dominic Raferd ha scritto: On Mon, 9 Dec 2019 at 14:13, Simone Marchioni > wrote: I have a problem with Postfix. Recently we are receiving mail messages with malformed "From:" headers as these: From: "Name Surname

Re: Postfix header_checks not working: Invalid preceding regular expression

On 09 Dec 2019, at 07:12, Simone Marchioni wrote: > I have a problem with Postfix. Recently we are receiving mail messages with > malformed "From:" headers as these: > > From: "Name Surname " > From: "u...@good-domain.com" There is nothing malformed about these headers. -- A closed

Re: Postfix header_checks not working: Invalid preceding regular expression

On Mon, 9 Dec 2019 at 14:13, Simone Marchioni wrote: > I have a problem with Postfix. Recently we are receiving mail messages > with malformed "From:" headers as these: > > From: "Name Surname " > From: "u...@good-domain.com" > > Ended up with a solution based on PCRE header checks, with these

Postfix header_checks not working: Invalid preceding regular expression

I have a problem with Postfix. Recently we are receiving mail messages with malformed "From:" headers as these: From: "Name Surname " From: "u...@good-domain.com" Ended up with a solution based on PCRE header checks, with these two regexp: /^From:.+(".+<(.*@+.*)>").*<((?!\2).*)>$/ REJECT

dkim: FAILED Author+Sender+MailFrom signature by d=gmail.com, From: , a=rsa-sha256, c=relaxed/relaxed, s=20161025, i=@gmail.com, invalid (public key: DNS error: no nameservers)

Dear, I've a Postfix server where I've implemented DKIM for incoming mails. While receiving mails, I'm seeing the /var/log/zimbra.log file and I can see a type of error as in below case corresponds to a mail sent from Gmail to my Zimbra account: dkim: FAILED Author+Sender+MailFrom signature by

Re: config check

> On 09 Dec 2019, at 00:17, Felix Rubio wrote: > > Allow unencrypted/unauthenticated users to submit mail from local > (127.0.0.x) connections There is no need for this, and it is dangerous. Just because a connection is local doesn’t mean it is trustworthy. >mynetworks =

Re: config check

Hi Viktor, Thank you very much for your answer. I really appreciate the time you took to go through it. The reason for having the tls/auth parameters configured was, actually, a requirement I did not write (sorry for that, I wrote the mail in a hurry :-/): - Require encrypted and

Re: Unable to send mail via "smtp.office365.com"

Gerard E. Seibert: > On Sun, 8 Dec 2019 21:52:39 +0100, Patrick Ben Koetter stated: > >* Gerard E. Seibert : > >> Thank you for that quick and accurate answer. I was just wondering, > >> is this a bug in 'libsasl' or is it due to a change in Outlook? My > >> setup had been working for years

Re: Advice: NFS, hardware, SATA vs SAS etc

venbian: > You ruled out cloud solutions? Someone: > Yes. Do any Postfix administrators with busy systems rely on NFS? On 6/12/19 8:12 pm, Wietse Venema wrote: > It can be done, provided that one does not do stupid things like > logging into the NFS server and messing with files that an NFS >

Re: Unable to send mail via "smtp.office365.com"

On Sun, 8 Dec 2019 21:52:39 +0100, Patrick Ben Koetter stated: >* Gerard E. Seibert : >> Thank you for that quick and accurate answer. I was just wondering, >> is this a bug in 'libsasl' or is it due to a change in Outlook? My >> setup had been working for years without any errors. > >It's very

Re: Advice: NFS, hardware, SATA vs SAS etc

On 6/12/19 8:12 pm, Wietse Venema wrote: venbian: You ruled out cloud solutions? Yes. Do any Postfix administrators with busy systems rely on NFS? It can be done, provided that one does not do stupid things like logging into the NFS server and messing with files that an NFS client is