Re: Various questions about Postfix
On Sat, Nov 06, 2021 at 11:38:26PM -0500, Tyler Montney
wrote:
> Sorry for the long delay, wanted to do more research before posting it.
> I've replaced some real values, like myhostname, with generic ones.
I expect it's all fine or you would have had a response by now.
I'll have a look and make comments, but be warned that I might
easily misunderstand something and say something dumb. So don't
take it too seriously.
> postconf -nf
>
> command_directory = /usr/sbin
You seem to be explicitly setting many parameters to their defaults.
That's harmless but unnecessary.
> content_filter = smtp-amavis:[127.0.0.1]:10024
With a content filter, you want to only do address
mappings before or after the filter, not both. You have
the address mappings happening before, which means that
the filter doesn't have access to the original
addresses. It only has access to the mapped addresses.
That might be want you want. You have suppressed
address mappings after the filter by having this in
master.cf for the 127.0.0.1:10025 service:
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_address_mappings
If you'd prefer to make the original addresses
available to the content filter, you could instead have
"receive_override_options = no_address_mappings" in
main.cf and remove "no_address_mappings" from
master.cf.
Both ways are fine.
However, I think you might want to add "no_milters" to
the receive_override_options parameter in master.cf.
Otherwise, the milters will probably run both before
and after the filter. It's unlikely that that's what
you want (but it might be - I don't know what the
milter on port 11332 is doing).
> header_checks = regexp:/etc/postfix/header_checks
> mime_header_checks = regexp:/etc/postfix/header_checks
If you have pcre available (it's a separate package on
Debian), you might want to use that instead of regexp
because pcre is faster.
> inet_interfaces = 192.168.0.3, 127.0.0.1
This probably isn't needed unless there are
other IP addresses that you want to exclude.
> inet_protocols = ipv4
This probably isn't needed unless you have IPv6 but
don't want to use it.
> message_size_limit = 52428800
> virtual_mailbox_limit = 524288
message_size_limit needs to be less than or equal to
virtual_mailbox_limit. Your virtual_mailbox_limit is
100 times message_size_limit. So that's fine, but they
could also be equal. I don't know if there's a reason
for virtual_mailbox_limit to be so much larger than
message_size_limit.
> milter_default_action = accept
> milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
I don't know enough to comment sensibly on this. The
only milters I use are opendkim and opendmarc, and I
leave milter_mail_macros at it's default value. But
even if the milter on port 11332 needs the addition of
{client_addr} {client_name}, there's probably no reason
to remove {auth_type} {auth_author} {mail_host}. But I
expect that you understand this much better than I do,
so ignore the above. :-)
> mydestination = localhost.$mydomain, localhost
> myhostname = mail.foo.com
> mailbox_transport = lmtp:unix:private/dovecot-lmtp
Removing $myhostname from mydestination looks unusual
to me. I assume there's a good reason, but since you
have local delivery (using lmtp and dovecot in
mailbox_transport), it seems odd that the mail server's
hostname can't be used in an email address for the
local users. I assume that you just want locally
originating email for local users, and you want that
local email to be delivered to a dovecot mailbox.
So it's probably all fine.
> smtp_tls_mandatory_protocols = >=TLSv1.2
> smtp_tls_protocols = >=TLSv1.2
This can lead to your mail server transmitting email
unencrypted if the receiving server doesn't support
TLSv1.2 but does support TLSv1.0 or TLSv1.1. That
doesn't really do anyone any favours. Remember that
SMTP encryption is opportunistic. If you are too fussy,
you get nothing. SSLv2 and SSLv3 should be excluded
because they are broken, but TLSv1.0 and TLSv1.1 are
still OK to use for mail (even though they are
deprecated).
Even if you have some security theatre requirements not
to accept TLSv1.0 on your mail server, that is achieved
with the smtpd_ equivalents of these parameters
(below). As far as I am aware, nothing scans which
protocols are supported by your server for outgoing
mail.
> smtp_tls_security_level = may
This is fine, but you might be able to do better. If
your mail server runs a local DNSSEC-validating name
resolver (e.g., Bind9 or Unbound), then you could make
Postfix DANE-aware and avoid falling prey to
man-in-the-middle attacks when sending mail to remote
SMTP servers that implement DANE. To do this, your
/etc/resolv.conf would need to look something like this:
nameserver 127.0.0.1
options trust-ad
(with no other nameserver entries), and then you would replace
"smtp_tls_security_level = may" in main.cf with:
smtp_dns_support_level = dnssec
smtp_tls_security_level =
domain email handled by postfix
How to set up postfix to forward all my domain's email to gmail, and enable authentication for SMTP outgoing messages? Thank you.
Re: How to reject generic FCrDNS clients
On Thu, Nov 11, 2021 at 08:53:01PM +0100, Togan Muftuoglu wrote: > Matus> /(\d+)[.-](\d+)[.-](\d+)[.-](\d+)./ REJECT "generic DNS refused" > > Matus> (trailing . should avoid matching IP Addresses) That "." would need to be a "[.]" (or "\."), otherwise it'll match the last digit, of a 2 or 3 decimal digit IP octet. But I think that Matus intended to also allow other non-digit charaters, therefore the correct regular expression is: /(\d+)[.-](\d+)[.-](\d+)[.-](\d+)\D/ REJECT "generic DNS refused" Broken: $ postmap -q "172.31.12.175" pcre:<( printf '%s\n/^/ DUNNO\n' '/(\d+)[.-](\d+)[.-](\d+)[.-](\d+)./ REJECT "generic DNS refused"' ) REJECT "generic DNS refused" Working: $ postmap -q "172.31.12.175" pcre:<( printf '%s\n/^/ DUNNO\n' '/(\d+)[.-](\d+)[.-](\d+)[.-](\d+)\D/ REJECT "generic DNS refused"' ) DUNNO I must some day stop being surprised about all the sloppy regular expressions I run into. Regular expressions are programs for a suitable automaton, pay attention to detail! -- Viktor.
Re: Postfix unable to locate opendmarc.sock file
On Thu, Nov 11, 2021 at 06:39:27PM -0500, bobby 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: Postfix unable to locate opendmarc.sock file
On 2021-11-11 at 18:39:27 UTC-0500 (Thu, 11 Nov 2021 18:39:27 -0500) bobby is rumored to have said: 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 That is not the syntax for smtpd_milters. See http://www.postfix.org/MILTER_README.html. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Postfix unable to locate opendmarc.sock file
bobby: > 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 See http://www.postfix.org/MILTER_README.html for smtpd_milters syntax. Wietse
Re: How to reject generic FCrDNS clients
> "toganm" == Togan Muftuoglu writes: > "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) toganm> I tried it with the as toganm> smtpd_client_restrictions = usual stuff toganm> check_client_access pcre: ^^ Mea culpa, I should have double checked what I typed. Currently testing with DUNNO
Postfix unable to locate opendmarc.sock file
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
Re: How to reject generic FCrDNS clients
> "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. 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. 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=
Re: How to reject generic FCrDNS clients
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.) -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: How to reject generic FCrDNS clients
> "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) Thank you Togan
Re: How to reject generic FCrDNS clients
> "ptld" == postfix writes: >> How can I reject connections from generic Forward Confirmed Reverse DNS >> (FCrDNS) like “123-45-67-8.your.isp.com”. ptld> I do not know if there is an easier way but you could make a script using ptld> check_policy_service or a milter to check if client name contains client ptld> IP. However i wonder how complicated the filter rules would be ptld> considering IPv6 and the different ways an address could be abbreviated. ptld> I have also seen some providers reverse the IPv4 in the FQDN. Also some ptld> legit mailers include the last part of the servers IP in the FQDN for ptld> large companies with many servers like gmail/google. I am interested only in IPv4. I know with Spamhaus some ISPs, Cloud Service Providers are blocked with policy block lists. Funny I discovered this when I wanted to register to barracudacentral.org rbl. It was blocked by Spamhaus. Now they have cleared their AWS ip from Spamhaus and this time their DMARC policy is rejected them.
Re: How to reject generic FCrDNS clients
> "Ludi" == Ludi Cree writes: Ludi> Root Servers / IPs at datacenters often also get a default RDNS in that Ludi> style. Greets, Ludi Yes but if you own the domain you can ask the datacenters/cloud centers for the RDNS and your helo will match your RDNS. I am using AWS and it was done in a couple of minutes via the console. So it is possible Togan
Re: How to reject generic FCrDNS clients
On 11.11.21 12:06, Togan Muftuoglu wrote: >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 you can check hostnames by using pcre map in check_reverse_client_hostname_access. e.g. refuse regex /(\d+)[.-](\d+)[.-](\d+)[.-](\d+)./ REJECT "generic DNS refused" (trailing . should avoid matching IP Addresses) -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Nothing is fool-proof to a talented fool.
AW: How to reject generic FCrDNS clients
Root Servers / IPs at datacenters often also get a default RDNS in that style. Greets, Ludi -Ursprüngliche Nachricht- Von: owner-postfix-us...@postfix.org Im Auftrag von post...@ptld.com Gesendet: Donnerstag, 11. November 2021 14:56 An: postfix-users@postfix.org Betreff: Re: How to reject generic FCrDNS clients > How can I reject connections from generic Forward Confirmed Reverse DNS > (FCrDNS) like “123-45-67-8.your.isp.com”. I do not know if there is an easier way but you could make a script using check_policy_service or a milter to check if client name contains client IP. However i wonder how complicated the filter rules would be considering IPv6 and the different ways an address could be abbreviated. I have also seen some providers reverse the IPv4 in the FQDN. Also some legit mailers include the last part of the servers IP in the FQDN for large companies with many servers like gmail/google.
Re: How to reject generic FCrDNS clients
> How can I reject connections from generic Forward Confirmed Reverse DNS > (FCrDNS) like “123-45-67-8.your.isp.com”. I do not know if there is an easier way but you could make a script using check_policy_service or a milter to check if client name contains client IP. However i wonder how complicated the filter rules would be considering IPv6 and the different ways an address could be abbreviated. I have also seen some providers reverse the IPv4 in the FQDN. Also some legit mailers include the last part of the servers IP in the FQDN for large companies with many servers like gmail/google.
Re: Getting Delivered-To when using LDAP?
Jorgen Lundman: > >> I suppose there is probably nothing I can do about it? > > > > http://www.postfix.org/postconf.5.html#prepend_delivered_header > > > > currenly immplements (and detects loops) with delivery to "|command", > > /file/name, or !$HOME/.forward. > > > > Doing this also for virtual alias expansion would require new code > > that currently does not exist. > > > > Note that loop detection requires that the existing Delivered-To: > > headers are known. That could be a problem because virtual alias > > expansion happens before the headers are received. > > > > Wietse > > I suspected as such, I just wanted some authority behind me before I > send the reply upstream. > > Thank you, for everything, It would be technically possible, but the question hasn't come up in the first 20+ years of life with Postfix. Wietse
Re: Getting Delivered-To when using LDAP?
>> I suppose there is probably nothing I can do about it? > > http://www.postfix.org/postconf.5.html#prepend_delivered_header > > currenly immplements (and detects loops) with delivery to "|command", > /file/name, or !$HOME/.forward. > > Doing this also for virtual alias expansion would require new code > that currently does not exist. > > Note that loop detection requires that the existing Delivered-To: > headers are known. That could be a problem because virtual alias > expansion happens before the headers are received. > > Wietse I suspected as such, I just wanted some authority behind me before I send the reply upstream. Thank you, for everything, Lund
How to reject generic FCrDNS clients
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 Thanks Togan
Re: Getting Delivered-To when using LDAP?
Joergen Lundman: > > Customers have asked if they can get the "Delivered-To" header in the case > that their > mail is sent onwards. But we do not use the regular .forward or "delivery" > style, but > rather query LDAP for "mailForwardingAddress" to send mail on. > > As in: > virtual_mailbox_maps = ldap:/etc/postfix/ldap-accounts.cf > virtual_mailbox_domains = ldap:/etc/postfix/ldap-domains.cf > virtual_alias_maps = ldap:/etc/postfix/ldap-forwardonly.cf, > ldap:/etc/postfix/ldap-forwards.cf > > So I think we have the problem that we are not actually delivering anything > but rather "relay"ing it onwards, so the option " prepend_delivered_header" > does not apply here? > > I suppose there is probably nothing I can do about it? http://www.postfix.org/postconf.5.html#prepend_delivered_header currenly immplements (and detects loops) with delivery to "|command", /file/name, or !$HOME/.forward. Doing this also for virtual alias expansion would require new code that currently does not exist. Note that loop detection requires that the existing Delivered-To: headers are known. That could be a problem because virtual alias expansion happens before the headers are received. Wietse
