Re: Postfix unable to locate opendmarc.sock file
> On 12 Nov 2021, at 8:00 pm, post...@ptld.com wrote: > > While it will technically work, i believe it is bad practice and sockets > should be under the /run/ directory. Im not 100% on this but i think running > it under /var/spool/ uses the hard drive while under /run/ its a ram-drive > only existing in memory for better performance. The cost of inode is negligible, it then doesn't change for the lifetime of the process. The advantage of placing the socket under /var/spool/postfix/ is that one can make that work for chrooted processes. If chroot is not and will not be used, then other locations are available and may be slightly advantageous. -- Viktor.
Re: Postfix unable to locate opendmarc.sock file
> On 11-12-2021 5:11 pm, bobby wrote: > So my opendkim file is located here: > /var/spool/postfix/opendkim/opendkim.sock > Do I need to move that, or is that location OK? While it will technically work, i believe it is bad practice and sockets should be under the /run/ directory. Im not 100% on this but i think running it under /var/spool/ uses the hard drive while under /run/ its a ram-drive only existing in memory for better performance.
Re: Postfix unable to locate opendmarc.sock file
> On 11-12-2021 5:11 pm, bobby wrote: > As for the opendmarc.sock, I was not able to locate that file on my system. Did you install opendmarc? Look in the config /etc/opendmarc.conf to see what the socket is set to. If its not set then its using default. Mine is set as: Socket local:/var/run/opendmarc/opendmarc.sock http://www.trusteddomain.org/opendmarc/opendmarc.conf.5.html SOCKET: Specifies the socket that should be established by the filter to receive connections from sendmail(8) in order to provide service. socketspec is in one of two forms: local:path, which creates a UNIX domain socket at the specified path, or inet:port[@host] or inet6:port[@host] which creates a TCP socket on the specified port for the appropriate protocol family. If the host is not given as either a hostname or an IP address, the socket will be listening on all interfaces. This option is mandatory either in the configuration file or on the command line. If an IP address is used, it must be enclosed in square brackets.
Re: Various questions about Postfix
On Fri, Nov 12, 2021 at 03:47:22PM -0600, Tyler Montney wrote: > In my effort to be a little less flexible (to get more encryption), it > seems I'll do the opposite. I'll change that. Speaking of which... > > smtp_tls_mandatory_protocols Applies when sending mail to destinations for which TLS is mandatory, i.e. the effective security level is "encrypt" or higher. With "dane" that means that the remote MX host is actually in a DNSSEC-signed zone and has TLSA records, otherwise "dane" gracefully degrades to "may". > smtp_tls_protocol Applies when the security level is "may", or "dane" and the MX host is not in a signed zone and/or does not have TLSA records. The "smtpd_" analogues are similar, "mandatory" is for submission where you'd typically set the security level to "encrypt". -- Viktor.
Re: Postfix unable to locate opendmarc.sock file
So my opendkim file is located here: /var/spool/postfix/opendkim/opendkim.sock Do I need to move that, or is that location OK? As for the opendmarc.sock, I was not able to locate that file on my system. On Thu, Nov 11, 2021 at 9:12 PM raf wrote: > On Thu, Nov 11, 2021 at 06:39:27PM -0500, bobby < > architectofthefut...@gmail.com> wrote: > > > I see this error message in my mail.log file: > > Nov 11 19:37:52 mail postfix/smtpd[5942]: warning: connect to Milter > > service local:opendmarc/opendmarc.sock: No such file or directory > > In the main.cf file, I have this line: > > smtpd_milters = > local:opendkim/opendkim.sock,local:opendmarc/opendmarc.sock, > > local:spamass/spamass.sock > > Firstly, while "local:" does work (for obscure reasons), it's not > documented, > and should be "unix:" instead. > > Secondly, the socket paths should either have "/run/" > or "/var/run/" at the start. This is assuming that the > sockets are in either of these two pairs of locations: > > /var/spool/postfix/run/opendkim/opendkim.sock > /var/spool/postfix/run/opendmarc/opendmarc.sock > > /var/spool/postfix/var/run/opendkim/opendkim.sock > /var/spool/postfix/var/run/opendmarc/opendmarc.sock > > See your /etc/opendkim.conf and /etc/opendmarc.conf to > see the real paths. Sometimes it's in /var/run. > Sometimes it's in /run. Sometimes it's neither. Your > config assumes: > > /var/spool/postfix/opendkim/opendkim.sock > /var/spool/postfix/opendmarc/opendmarc.sock > > And that's probably incorrect. > > cheers, > raf > >
Re: Various questions about Postfix
"You seem to be explicitly setting many parameters to their defaults." I removed a bunch, but might have missed some. That "command_directory" parameter I definitely didn't set. I think that's a result of building from source. "You have the address mappings happening before, which means that the filter doesn't have access to the original addresses." I was unaware entirely. I'm thinking I probably want the original addresses? "I don't know what the milter on port 11332 is doing" Believe that's rspamd. "But I expect that you understand this much better than I do" I've gotten into "from scratch" mail hosting a couple months back. I've done all I can to learn before asking questions. I want to know the reason why I put each line of config. "Removing $myhostname from mydestination looks unusual to me. I assume there's a good reason" That was early on in my research. Believe it had something to do with Postfix saying my LDAP user didn't exist. Removing it allowed delivery. "This can lead to your mail server transmitting email unencrypted" In my effort to be a little less flexible (to get more encryption), it seems I'll do the opposite. I'll change that. Speaking of which... smtp_tls_mandatory_protocols smtp_tls_protocol What is the difference between these two? I've read the docs but it didn't help. "then you could make Postfix DANE-aware and avoid falling prey to man-in-the-middle attack" Going to have to brush up on this. I have my AD PDC running DNS. Does it have to be localhost or can it be LAN? "You might want to add "silent-discard" to the above to suppress warnings in your log files about it." Good call, I was noticing that a bit. I'm sure when it goes into production that error would've annoyed me. "I assume port 10023 is running Postgrey." Correct. "smtpd_sasl_auth_enable shouldn't be in main.cf." Ah, because that would set the default across everything and we prefer it on 587. "That limits authentication attempts (successful or not" Do you have a specific recommendation on anvil or just pointing out what that parameter does? "you eliminate the chance of a race condition when Postfix reads the new key and chain" Race condition on renewal? If this happened, what would the effects look like? An untrusted certificate until I reload? "if you set up a renewal hook that executes a script like this" Thanks, saves me some work. "It's best not to disable_dns_lookups. The Amavis guide says to do it" It's tough to find much of anything on Amavis. Nowhere near as documented as Postfix and Dovecot. Is it still a good one to go with? "Yep." Does this mean "ditto" or "OK don't change"? "you might also want to add SPF checking" I did have 'postfix-policyd-spf-perl' but noticed OpenDMARC offers SPF. I have it set to always check even if the headers are provided. Or am I misunderstanding? Thanks for taking the time to review this. I feel confident now in putting it online (after I make a few of your adjustments).
Re: domain email handled by postfix
On 2021-11-12 at 12:07:43 UTC-0500 (Fri, 12 Nov 2021 12:07:43 -0500) Miles Fidelman is rumored to have said: Forwarding mail - that would be a job for procmail - pretty easy. Please, no. Procmail has been unmaintained for 2 decades and its security is unknowable beyond a certainty that there are unfixed bugs. Don't encourage anyone to install it anywhere it is not already infesting a system. (Full disclosure: yes, I do still have a .procmailrc handling my personal mail. Because I'm a lazy bozo.) -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: domain email handled by postfix
Ralph Seichter: > * Walt Pang: > > > How to set up postfix [...] > > Studying http://www.postfix.org/documentation.html first, in depth, will > help you. It is best always do one's homework before asking others. Read enough so that you can ask meaningful questions and understand the responses. No need to get stuck looking for the needle in the haystack. Wietse
Re: domain email handled by postfix
* Walt Pang: > How to set up postfix [...] Studying http://www.postfix.org/documentation.html first, in depth, will help you. It is best always do one's homework before asking others. -Ralph
Re: domain email handled by postfix
Walt Pang wrote: How to set up postfix to forward all my domain's email to gmail, and enable authentication for SMTP outgoing messages? Forwarding mail - that would be a job for procmail - pretty easy. SMTP authentication - last time I did that, I just went to the (rather excellent) postfix documentation. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. In our lab, theory and practice are combined: nothing works and no one knows why. ... unknown
Re: normally accepted *_maps-settings refused if inside a pipemap chain
Mirko Vogt:
>transport_maps =
> pipemap:{proxy:mysql:/etc/postfix/sql/mysql_transport_maps.cf,
> inline:{FOO=BAR}}
...
> Is postfix complaining about the "proxy:mysql:" transport setting within
> a pipemap-chain expected behaviour or potentially a bug? If the former,
> may I ask about the reasoning?
If you look at the default setting for proy_read_maps, then you
will see that it does not contain
"proxy:mysql:/etc/postfix/sql/mysql_transport_maps.cf". Instead
it contains that string inside pipemap{}.
The proxy_read_maps fature uses a generic list matcher that knows
nothing about Postfix maps, that does not look inside pipemap{}.
That would require a dedicated matcher.
Wietse
Re: How to reject generic FCrDNS clients
On 2021-11-11 at 14:53:01 UTC-0500 (Thu, 11 Nov 2021 20:53:01 +0100) Togan Muftuoglu is rumored to have said: "Matus" == Matus UHLAR <- fantomas > writes: Matus> you can check hostnames by using pcre map in Matus> check_reverse_client_hostname_access. e.g. refuse regex Matus> /(\d+)[.-](\d+)[.-](\d+)[.-](\d+)./ REJECT "generic DNS refused" Matus> (trailing . should avoid matching IP Addresses) I tried it with the as smtpd_client_restrictions = usual stuff check_client_access pcre: /etc/postfix/check_reverse_client_hostname_access.pcre Unfortunately the regex matches legitimate senders as well. As such a check always will. Legitimate senders, particularly large ones, frequently use generic names. Simplistic patterns will match hosts sending wanted mail. I had INFO instead of REJECT and that save the situation and the mails arrived. Have I placed the check in the wrong place or am I back to square one. Seems fine to me. Assuming you did not make an error in /etc/postfix/check_reverse_client_hostname_access.pcre, check_client_access in smtpd_client_restrictions would be the first place you can do the check. If you put it in a later restriction list you can use 2021-11-11T19:10:01.014343+01:00 myserver postfix/smtpd[3837]: Anonymous TLS connection established from mx1.goodserver.org[172.31.12.175]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 2021-11-11T19:10:01.062736+01:00 myserver postfix/smtpd[3837]: NOQUEUE: info: RCPT from mx1.goodserver.org[172.31.12.175]: "generic RDNS"; from= to= proto=ESMTP helo= The munging of all the IPs and hostnames in those log lines makes them entirely pointless. For all we know from that, the pattern match was correct. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
normally accepted *_maps-settings refused if inside a pipemap chain
Hello,
I'm having a working virtual user/mailbox setup, where I use mysql as
database backend and query it via "[..]_maps = proxy:mysql:[..]"-settings.
I now played around with the lookup table type "pipemap", wrapping the
previous setting(s) within a pipemap chain, e.g.
transport_maps =
pipemap:{proxy:mysql:/etc/postfix/sql/mysql_transport_maps.cf,
inline:{FOO=BAR}}
however postfix complains about it stating
warning: request for unapproved table:
"mysql:/etc/postfix/sql/mysql_transport_maps.cf"
warning: to approve this table for read-only access, list
proxy:mysql:/etc/postfix/sql/mysql_transport_maps.cf in
main.cf:proxy_read_maps
which seems quite odd, given that the "proxy:mysql:" setting works fine
without the pipemap around.
I then tried to add
"proxy:mysql:/etc/postfix/sql/mysql_transport_maps.cf" to
$proxy_read_maps explicitly, when realising, I can't simply add, but
only (re)set variables (please correct me if I'm wrong here).
Trying to get away from copying all the default values for
$proxy_read_maps, I tried
proxy_read_maps = $proxy_read_maps
proxy:mysql:/etc/postfix/sql/mysql_transport_maps.cf
which states
warning: unreasonable macro call nesting: "proxy_read_maps"
fatal: dictionary mail_dict: macro processing error
which I have to say I do not find unreasonable at all :)
Anyway, I now ended up with
proxy_read_maps = [output from `postconf -dfh proxy_read_maps`]
proxy:mysql:/etc/postfix/sql/mysql_transport_maps.cf
which does the job, however feels at least a bit clumsy.
Is postfix complaining about the "proxy:mysql:" transport setting within
a pipemap-chain expected behaviour or potentially a bug? If the former,
may I ask about the reasoning?
Thanks a lot
mirko
Re: How to reject generic FCrDNS clients
On 2021-11-12 at 06:57:14 UTC-0500 (Fri, 12 Nov 2021 12:57:14 +0100) Togan Muftuoglu is rumored to have said: "DMO" == Demi Marie Obenour writes: DMO> On 11/11/21 10:28 AM, Bill Cole wrote: On 2021-11-11 at 06:06:45 UTC-0500 (Thu, 11 Nov 2021 12:06:45 +0100) Togan Muftuoglu is rumored to have said: Hi, How can I reject connections from generic Forward Confirmed Reverse DNS (FCrDNS) like “123-45-67-8.your.isp.com”. For the most cases spamhaus is able to block it but with the cloud providers with FCrDNS as follows not all of them are not blocked. 123-45-67-89.ip.linodeusercontent.com ec2-12-34-56-789.us-west-2.compute.amazonaws.com How can I reject these connections DMO> Do all of the major mail service providers have valid DMARC? If so, one DMO> approach would be to reject (or, more likely, quarantine) mail from such DMO> hosts *unless* DMARC matches. That would require an external tool, DMO> though. When there is dmarc = none it doesn't work, and I would rather stop the connection request at the very beginning, meaning if your rDNS is not who you are claiming to be then sorry. The rDNS being generic is very different from rDNS being wrong. Generic rDNS is lazy, but it's not inherently deceptive. Postfix has long had simple reject_* directives for shunning clients with no PTR record and for those with a rDNS name that doesn't resolve back to the client IP. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: domain email handled by postfix
On 12/11/2021 04:53, Walt Pang wrote: How to set up postfix to forward all my domain's email to gmail, and enable authentication for SMTP outgoing messages? The good news is that we have had this working for our own domains for years. The bad news is that I don't have the time to explain our somewhat involved setup here, sorry. Maybe someone else can?
Re: How to reject generic FCrDNS clients
> "DMO" == Demi Marie Obenour writes: DMO> On 11/11/21 10:28 AM, Bill Cole wrote: >> On 2021-11-11 at 06:06:45 UTC-0500 (Thu, 11 Nov 2021 12:06:45 +0100) Togan >> Muftuoglu is rumored to have said: >> >>> Hi, >>> >>> How can I reject connections from generic Forward Confirmed Reverse DNS >>> (FCrDNS) like “123-45-67-8.your.isp.com”. >>> >>> >>> For the most cases spamhaus is able to block it but with the cloud >>> providers with FCrDNS as follows not all of them are not blocked. >>> >>> 123-45-67-89.ip.linodeusercontent.com >>> >>> ec2-12-34-56-789.us-west-2.compute.amazonaws.com >>> >>> >>> How can I reject these connections >> DMO> Do all of the major mail service providers have valid DMARC? If so, one DMO> approach would be to reject (or, more likely, quarantine) mail from such DMO> hosts *unless* DMARC matches. That would require an external tool, DMO> though. When there is dmarc = none it doesn't work, and I would rather stop the connection request at the very beginning, meaning if your rDNS is not who you are claiming to be then sorry.
Re: How to reject generic FCrDNS clients
On 11/11/21 10:28 AM, Bill Cole wrote: > On 2021-11-11 at 06:06:45 UTC-0500 (Thu, 11 Nov 2021 12:06:45 +0100) > Togan Muftuoglu > is rumored to have said: > >> Hi, >> >> How can I reject connections from generic Forward Confirmed Reverse >> DNS >> (FCrDNS) like “123-45-67-8.your.isp.com”. >> >> >> For the most cases spamhaus is able to block it but with the cloud >> providers >> with FCrDNS as follows not all of them are not blocked. >> >> 123-45-67-89.ip.linodeusercontent.com >> >> ec2-12-34-56-789.us-west-2.compute.amazonaws.com >> >> >> How can I reject these connections > > The canonical answer is "check_client_access with a pcre table" but if > you want something comprehensive that you don't need to actively manage > yourself you should consider the "Enemies List" service: > http://enemieslist.com. They use a rich set of non-obvious name patterns > and important exceptions. You likely do NOT want to arbitrarily reject > all mail from all hosts with programmatically IP-derived names, unless > you are intending to engage in a secondary boycott of major mail service > providers' (e.g. Microsoft) customers. > > (and no, I'm not affiliated with them in any way.) Do all of the major mail service providers have valid DMARC? If so, one approach would be to reject (or, more likely, quarantine) mail from such hosts *unless* DMARC matches. That would require an external tool, though. Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
