providing queue id for the clients
Hi, It turned out during an investigation that our postfix servers don't provide a queue id for the external clients when accepting a new email. However the very same servers do provide queue id for internal mail servers. Is there a specific configuration option to provide the queue id under any circumstances? Thank you, Zsombor
Re: User script for modifying main.cf and other config files
On Mon, Feb 08, 2021 at 03:47:27PM -0500, Alex wrote:
> I still have to consider much of what you've written before I can
> respond, but I wanted to be sure my design was clear here - it's not
> so much that end-users are modifying the config in the same way as
> webmin does, like making changes directly to main.cf, but type in the
> name of a new domain to be added to relay_domains, for example. The
> script then then modifies main.cf to apply that change.
If the goal is to just modify *data* elements in main.cf, and not
structural settings, then in the vast majority of cases specific
data elements can be set via separate files or database tables.
# File with one domain per-line
#
relay_domains = ${config_directory}/relay_domains
# An indexed file with ignored non-empty RHS
#
relay_domains = cdb:${config_directory}/relay_domains
# An LDAP table, with data managed centrally.
#
relay_domains = ldap:${config_directory}/relay_domains.cf
...
As much as possible, avoid pasting user-provided strings directly
into main.cf and master.cf.
For directly editing the files, one might employ a git repository
to which only authorised administrators can push commits, and where
to keep routine changes simple there's separation between a template
for expert users and parameter values applied to the template that
are ideally less error-prone in the hands of less-expert users.
--
Viktor.
Re: User script for modifying main.cf and other config files
On Mon, 8 Feb 2021, Alex wrote: > I still have to consider much of what you've written before I can > respond, but I wanted to be sure my design was clear here - it's not so > much that end-users are modifying the config in the same way as webmin > does, like making changes directly to main.cf, but type in the name of a > new domain to be added to relay_domains, for example. The script then > then modifies main.cf to apply that change. Then configure main.cf to be "static" and refer to sql, ldap table lookups in relay_domains. It's much more easier and you don't need to give root access to anything for main.cf modifications. Best regards, Jozsef - E-mail : kad...@blackhole.kfki.hu, kadlecsik.joz...@wigner.hu PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics H-1525 Budapest 114, POB. 49, Hungary
Re: User script for modifying main.cf and other config files
Alex wrote: > it's not so much that end-users are modifying the config in the same > way as webmin does, like making changes directly to main.cf, but > type in the name of a new domain to be added to relay_domains, for > example. The script then then modifies main.cf to apply that change. In that case the expected thing would be to use database tables to hold those configuration values. Then have your web UI interface update those database tables. That obviates the need to modify the main.cf file. http://www.postfix.org/MYSQL_README.html This still places the general security of the system with the security of the web UI. Really no difference there. But it removes the need to edit the cf files. Let me gently suggest looking into holding the things you need to change in database tables. And then interfacing with those with your web UI. Then... Profit! :-) Bob
Re: User script for modifying main.cf and other config files
> > Perhaps passwordless sudo with the explicit ability to act on these > > files and reload/restart postfix? Is it okay to create a backup > > directory in /etc/postfix that's owned by this script user? > > I wonder what changes you need to make so frequently. Whatever they are, stop > and reconsider. There is no scenario where allowing users to alter your mail > config could be considered secure. I still have to consider much of what you've written before I can respond, but I wanted to be sure my design was clear here - it's not so much that end-users are modifying the config in the same way as webmin does, like making changes directly to main.cf, but type in the name of a new domain to be added to relay_domains, for example. The script then then modifies main.cf to apply that change. I'm certainly not minimizing the risk - that's exactly why I'm posting here, but I'm hoping I can mitigate the most obvious problems and continue to make it more secure. > ¹ I am not specifically recommending webmin, I do not run it and I wold not > run it as I prefer accessing my server via ssh with a key exchange which can > only be duplicated if someone gets my private key file off my home machine, > or if someone can login to the console on-site as me. That's exactly how I've been doing it for decades now as well (I'm still no expert), but I'm hoping to create something that makes it easier for our local admins and perhaps others in the future.
Re: fork_attempts=10 ?
Marek Kozlowski wrote: > My system is not overloaded and - in many aspects quite typical one. Great! I believe you. But then there was absolutely no reason to double a limit that would never have been hit. If the system is not overloaded the the initial fork() will always succeed and there will never be any retries. Not five and therefore not ten either. > If I had to double some value something very strange must have > occurred. I'm wondering what was it (a black hole in my memory). That you did double that limit that was not getting hit (not getting hit because your system was not overloaded) then it changed something that had no effective change. In that case it was a noop. Because you were not hitting that limit. Because your system was not overloaded. And therefore there was no effect by changing it. That it was changed was likely simply a misunderstanding at that time. But now that it is later and we all have had more sleep since then and looking at it fresh we can see that it was simply a mistake. No big deal. Nothing to see. I make mistakes all of the time! And now that we know we should remove it from the local configuration and let it drop back to the default as part of the cleanup back to the mainstream. Bob
Re: TCP wrappers and Postfix
Thanks, Noel! Your comments are helpful indeed. пн, 8 февр. 2021 г. в 22:37, Noel Jones : > > On 2/8/2021 11:45 AM, Eugene Podshivalov wrote: > > Thanks for the explanation, Wietse. > > > > Probably the issue is just with the logging levels. > > My current configuration already has > > > > smtpd_client_restrictions=reject_unknown_client_hostname > > > > and the log file is flooded with message like this > > > > connect from unknown[ x.x.x.x] > > NOQUEUE: reject: CONNECT from unknown[ x.x.x.x]: 450 4.7.25 > > Client host rejected: cannot find your hostname > > That's a 450 temporary reject, so if it's a (semi-)legit mail server > it will likely try again and again. Bots tend to not come back. > > Try changing unknown_client_reject_code=550 to signal a permanent > reject. > > Also note that reject_unknown_client_hostname is a very strict test > and is known to reject some legit mail from slightly misconfigured > hosts, sometimes even major providers will fail this test. I'm not > telling you to not use this setting, but be aware that it will > eventually reject something you want. > It's safer to use reject_unknown_reverse_client_hostname. > > > > > which makes it hard to analyse. > > I fail to see how that makes analysis any harder. If your logs are > for more than a trivial amount of mail use "grep" to find the > interesting bits, and "less" to view. The "interesting bits" will > vary depending on what you're investigating. > > Or use a log summary tool such as pflogsumm or one of the others > listed at http://www.postfix.org/addon.html#logfile > > Make sure you don't have debug logs turned on, with a -D flag in > master.cf, or debug_peer_list, or [smtp|smtpd]_tls_loglevel greater > than 1 in main.cf. > > > > > > For comparison, the postscreen_*_action params let you `enforce` > > reject a delivery attempt and log it, or just 'drop' the connection > > silently. > > postscreen's drop action _does_not_ eliminate logging. The > connect/drop/disconnect is always logged. Drop does eliminate > logging of the sender and recipient, which is often useful. > > I respectfully suggest you don't waste your valuable time trying to > eliminate logging. Postfix logs what is necessary in order to trace > where mail came from and what happened to it. > > If you want to get rid of the logging (not recommended) use a log > filter such as rsyslogd or block the client IP in your firewall, or > use fail2ban to automatically block clients that make too many errors. > > > >-- Noel Jones >
Re: TCP wrappers and Postfix
On 2/8/2021 11:45 AM, Eugene Podshivalov wrote: Thanks for the explanation, Wietse. Probably the issue is just with the logging levels. My current configuration already has smtpd_client_restrictions=reject_unknown_client_hostname and the log file is flooded with message like this connect from unknown[ x.x.x.x] NOQUEUE: reject: CONNECT from unknown[ x.x.x.x]: 450 4.7.25 Client host rejected: cannot find your hostname That's a 450 temporary reject, so if it's a (semi-)legit mail server it will likely try again and again. Bots tend to not come back. Try changing unknown_client_reject_code=550 to signal a permanent reject. Also note that reject_unknown_client_hostname is a very strict test and is known to reject some legit mail from slightly misconfigured hosts, sometimes even major providers will fail this test. I'm not telling you to not use this setting, but be aware that it will eventually reject something you want. It's safer to use reject_unknown_reverse_client_hostname. which makes it hard to analyse. I fail to see how that makes analysis any harder. If your logs are for more than a trivial amount of mail use "grep" to find the interesting bits, and "less" to view. The "interesting bits" will vary depending on what you're investigating. Or use a log summary tool such as pflogsumm or one of the others listed at http://www.postfix.org/addon.html#logfile Make sure you don't have debug logs turned on, with a -D flag in master.cf, or debug_peer_list, or [smtp|smtpd]_tls_loglevel greater than 1 in main.cf. For comparison, the postscreen_*_action params let you `enforce` reject a delivery attempt and log it, or just 'drop' the connection silently. postscreen's drop action _does_not_ eliminate logging. The connect/drop/disconnect is always logged. Drop does eliminate logging of the sender and recipient, which is often useful. I respectfully suggest you don't waste your valuable time trying to eliminate logging. Postfix logs what is necessary in order to trace where mail came from and what happened to it. If you want to get rid of the logging (not recommended) use a log filter such as rsyslogd or block the client IP in your firewall, or use fail2ban to automatically block clients that make too many errors. -- Noel Jones
Re: TCP wrappers and Postfix
Eugene Podshivalov: > Thanks for the explanation, Wietse. > > Probably the issue is just with the logging levels. > My current configuration already has > > > smtpd_client_restrictions=reject_unknown_client_hostname > > and the log file is flooded with message like this > > > connect from unknown[ x.x.x.x] > > NOQUEUE: reject: CONNECT from unknown[ x.x.x.x]: 450 4.7.25 Client host > > rejected: cannot find your hostname > > which makes it hard to analyse. > > For comparison, the postscreen_*_action params let you `enforce` reject a > delivery attempt and log it, or just 'drop' the connection silently. Here is an idea open a shell window type: man 1 grep type: man 1 less
Re: postscreen
On 9/02/21 2:48 am, maciejm wrote: Hello What I must set to enable "postscreen" ? I ask because I must use "-o receive_override_options=no_address_mappings" in master.cf smtp inet n - y - 100 smtpd -o receive_override_options=no_address_mappings ... proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - y - - smtp -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 ... See the instructions at: http://www.postfix.org/POSTSCREEN_README.html#enable ...they explicitly say what to do with -o options to the smtp service. Peter
Re: postscreen
On 08.02.21 14:48, maciejm wrote: What I must set to enable "postscreen" ? On 08.02.2021 14:50, Matus UHLAR - fantomas wrote: it's described on: http://www.postfix.org/POSTSCREEN_README.html I ask because I must use "-o receive_override_options=no_address_mappings" in master.cf no, you usually don't have to do this, it should usually be used when receiving mail from content filter. On 08.02.21 14:57, maciejm wrote: I realy known what I need I have many alias group and others and this options I need (amavis+SA+other) and works perfectly. you can by default ahve this option when pushing the mail back from mail filter to postfix. Or, simply configure postscreen to PASS the mail to smtpd, as instructed on postscreen REASME, with with the -o option. smtp inet n - y - 100 smtpd -o receive_override_options=no_address_mappings ... proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - y - - smtp -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 ... -- 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. Linux IS user friendly, it's just selective who its friends are...
Re: Communication between postfix - amavis issues
On 8/2/2021 1:38 μ.μ., Matus UHLAR - fantomas wrote: that's not how milter works, unless you instructed amavisd-milter to deliver mail by server via "-D server" option. The default is "-D client", which means, amavisd instructs postfix what to do with the mail - reject/quarantine/pass it, add/remove/modify the headers etc. On 08.02.21 16:28, Nikolaos Milas wrote: Hmm, I see. It seems it's running in client mode, because I don't see any -D definition, so the default applies. So, milter delivers mail back to postfix for final delivery? no, milter (usually) just tells postfix what to do with mail. default is "accept". that's why there's just one mail and one mail ID visible in postfix logs, when mail is processed with milters. again, FILTER applies after mail is received, so next lines in log should show how the mail is delivered to amavis on port 10028 Next lines show that the mail is quarantined (it is an EICAR virus-test message, which should be quarantined if it does not by-pass through port 10028, as desired); here is the whole session: wrapping log lines is not a good idea... Feb 8 01:54:53 mailgw1 postfix/smtpd[202464]: connect from hedgehog.birch.relay.mailchannels.net[23.83.209.81] Feb 8 01:54:55 mailgw1 postfix/smtpd[202464]: NOQUEUE: filter: RCPT from hedgehog.birch.relay.mailchannels.net[23.83.209.81]: : Sender address triggers FILTER smtp:[127.0.0.1]:10028; from= to= proto=ESMTP helo= Feb 8 01:54:55 mailgw1 postfix/smtpd[202464]: 4DYmH36X5JzLlrw: client=hedgehog.birch.relay.mailchannels.net[23.83.209.81] Feb 8 01:54:56 mailgw1 postfix/cleanup[202468]: 4DYmH36X5JzLlrw: message-id=<464576df-43d0-ecac-5647-99c91a95c...@example.com> Feb 8 01:54:56 mailgw1 postfix/cleanup[202468]: 4DYmH36X5JzLlrw: milter-discard: END-OF-MESSAGE from hedgehog.birch.relay.mailchannels.net[23.83.209.81]: milter triggers DISCARD action; from= to= proto=ESMTP helo= Feb 8 01:54:56 mailgw1 postfix/smtpd[202464]: disconnect from hedgehog.birch.relay.mailchannels.net[23.83.209.81] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 this milter told postfix to discard the mail, so amavis/milter are responsible for what happens next to mail. I think this happens when "-D server" is used with amavisd-milter. The message is not honoring the bypass and gets quarantined. But if I don't send an infected message, the flow is clearer: First the message is delivered via the milter, scanned via the normal policy bank, and only AFTER that it is examined by the BYPASS policy bank! Here is a log: Feb 8 15:15:00 mailgw1 postfix/smtpd[219538]: connect from black.elm.relay.mailchannels.net[23.83.212.19] Feb 8 15:15:01 mailgw1 postfix/smtpd[219538]: Anonymous TLS connection established from black.elm.relay.mailchannels.net[23.83.212.19]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Feb 8 15:15:03 mailgw1 postfix/smtpd[219538]: NOQUEUE: filter: RCPT from black.elm.relay.mailchannels.net[23.83.212.19]: : Sender address triggers FILTER smtp:[127.0.0.1]:10028; from= to= proto=ESMTP helo= Feb 8 15:15:03 mailgw1 postfix/smtpd[219538]: 4DZ62H32SKzLm4t: client=black.elm.relay.mailchannels.net[23.83.212.19] Feb 8 15:15:04 mailgw1 postfix/cleanup[219533]: 4DZ62H32SKzLm4t: message-id=<3692cf3d-0de8-fe26-4541-c5876658b...@example.com> Feb 8 15:15:04 mailgw1 postfix/qmgr[202450]: 4DZ62H32SKzLm4t: from=, size=2167, nrcpt=1 (queue active) Feb 8 15:15:04 mailgw1 postfix/smtpd[219538]: disconnect from black.elm.relay.mailchannels.net[23.83.212.19] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 Feb 8 15:15:04 mailgw1 postfix/smtp[219543]: 4DZ62H32SKzLm4t: to=, relay=127.0.0.1[127.0.0.1]:10028, delay=2.1, delays=1.7/0.03/0.06/0.39, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4DZ62J63CZzLm4w) Feb 8 15:15:04 mailgw1 postfix/qmgr[202450]: 4DZ62H32SKzLm4t: removed Milter actions not logged here, which means milter let mail to pass. then I see that the mail is sent to [127.0.0.1]:10028, which further reports mail delivered back to postfix at [127.0.0.1]:10025 and in Amavis: Feb 8 15:15:04 mailgw1 amavis[219136]: loaded policy bank "AM.PDP-SOCK" Feb 8 15:15:04 mailgw1 amavis[219136]: process_request: fileno sock=19, STDIN=0, STDOUT=1 Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: request=AM.PDP Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: queue_id=4DZ62H32SKzLm4t Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: sender= Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: recipient= Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: tempdir=/var/spool/amavisd/tmp/afO7JePJ Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: tempdir_removed_by=client Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: mail_file=/var/spool/amavisd/tmp/afO7JePJ/email.txt Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: delivery_care_of=client Feb 8 15:
Re: TCP wrappers and Postfix
Thanks for the explanation, Wietse. Probably the issue is just with the logging levels. My current configuration already has > smtpd_client_restrictions=reject_unknown_client_hostname and the log file is flooded with message like this > connect from unknown[ x.x.x.x] > NOQUEUE: reject: CONNECT from unknown[ x.x.x.x]: 450 4.7.25 Client host > rejected: cannot find your hostname which makes it hard to analyse. For comparison, the postscreen_*_action params let you `enforce` reject a delivery attempt and log it, or just 'drop' the connection silently. Eugene пн, 8 февр. 2021 г. в 19:39, Wietse Venema : > Eugene Podshivalov: > > Have read through the postscreen documentation closely and got it setup > and > > running already, but could not find the three major possibilities > provided > > by the tcp wrappers: > > 1. block by hostname > > 2. block clients with unknown hostname > > 3. block clients with invalid address<->name mapping > > Those are implemented by http://www.postfix.org/smtpd.8.html > > Postscreen does not look up or verify the client hostname. > It is the FIRST line of defense; the more expensive checks > are done in other programs. In increasing order of cost, that's > postscreen, smtpd_mumble_restrictions, header/body_checks, and > content inspection with Milter, smtpd_proxy_filter, or FILTER. > > Wietse >
Re: User script for modifying main.cf and other config files
On 08 Feb 2021, at 09:44, Michael Ströder wrote: > On 2/8/21 2:28 PM, @lbutlr wrote: >> Use a tool like Webmin¹. > > IIRC webmin has a long history of security issues. They all do. >> It is, in my opinion a very very bad idea, > > I don't understand why you recommend something you consider a bad idea. Because despite being a terrible idea it is a thousand times better than what the OP is planning on doing. >> For user management, including admin access to hosted >> domains, a tool like postfixadmin seems to work pretty well. > Especially user management (or other volatile map) is better done in a > remote database like LDAP server, mysql etc. Postfixadmin is just a friendly interface into the mail sql database. -- "Are you pondering what I'm pondering?" "I think so, Ali-Brain! But isn't it cheating to use glue?"
Re: User script for modifying main.cf and other config files
On 2/8/21 2:28 PM, @lbutlr wrote: > Use a tool like Webmin¹. IIRC webmin has a long history of security issues. > It is, in my opinion a very very bad idea, I don't understand why you recommend something you consider a bad idea. > For user management, including admin access to hosted > domains, a tool like postfixadmin seems to work pretty well. Especially user management (or other volatile map) is better done in a remote database like LDAP server, mysql etc. Ciao, Michael.
Re: TCP wrappers and Postfix
Eugene Podshivalov: > Have read through the postscreen documentation closely and got it setup and > running already, but could not find the three major possibilities provided > by the tcp wrappers: > 1. block by hostname > 2. block clients with unknown hostname > 3. block clients with invalid address<->name mapping Those are implemented by http://www.postfix.org/smtpd.8.html Postscreen does not look up or verify the client hostname. It is the FIRST line of defense; the more expensive checks are done in other programs. In increasing order of cost, that's postscreen, smtpd_mumble_restrictions, header/body_checks, and content inspection with Milter, smtpd_proxy_filter, or FILTER. Wietse
Re: Stucked with "unable to look up host"
El lun., 8 de febrero de 2021 10:20, Matus UHLAR - fantomas < uh...@fantomas.sk> escribió: > On 31.01.21 09:56, Daniel Armando Rodriguez wrote: > >Indeed, it was running chrooted but resolv.conf has the same content > > >=== # postconf -nf > >smtp_tls_protocols = TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3 > > this is superflous and not a good idea. Many servers support TLS1.0 max. > !SSLv2, !SSLv3 should be enough for now. > > >After adjusting values the recommended way not getting > > > >connect to correo.dominio.com.ar[]:25: Connection timed out > > % host -t any correo.dominio.com.ar > Host correo.dominio.com.ar not found: 3(NXDOMAIN) > > correo.dominio.com.ar does not exist, so you can't send mail there. > It is also reason why it was not resolved. > That's not a real domain >and > > > >Jan 31 09:43:42 domiinio postfix/smtp[13099]: Untrusted TLS connection > >established to alt2.gmail-smtp-in.l.google.com[172.217.218.26]:25: > TLSv1.2 > >with cipher ECDHE-ECDSA-CHACHA20-POLY1305 (256/256 bits) > >Jan 31 09:43:42 dominio postfix/smtp[13099]: E6AA880124FF7: to=< > >u...@gmail.com>, relay=alt2.gmail-smtp-in.l.google.com > [172.217.218.26]:25, > >delay=40220, delays=40215/0/4.5/0, dsn=4.7.5, status=deferred (Server > >certificate not trusted) > > This is caused by your setting: > > >smtp_tls_security_level = verify > > smtp, by default, is plaintext, and encryption is not fully standard, so > you > disable sending mail to part of internet. > You're right, already noted that >
Re: TCP wrappers and Postfix
Do you mean with the help of reject_unknown_client_hostname and check_sender_access params? пн, 8 февр. 2021 г. в 16:37, Matus UHLAR - fantomas : > On 08.02.21 16:27, Eugene Podshivalov wrote: > >Have read through the postscreen documentation closely and got it setup > and > >running already, but could not find the three major possibilities provided > >by the tcp wrappers: > >1. block by hostname > >2. block clients with unknown hostname > >3. block clients with invalid address<->name mapping > > > >The last two produce the major bulk of spambot connections. > > >Are there any other means to achieve these? > > you can block these at smtpd level. > Postscreen doesn't (and won't) check for reverse hostname. > > -- > 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. > "The box said 'Requires Windows 95 or better', so I bought a Macintosh". >
Re: Communication between postfix - amavis issues
On 8/2/2021 1:38 μ.μ., Matus UHLAR - fantomas wrote: that's not how milter works, unless you instructed amavisd-milter to deliver mail by server via "-D server" option. The default is "-D client", which means, amavisd instructs postfix what to do with the mail - reject/quarantine/pass it, add/remove/modify the headers etc. Hmm, I see. It seems it's running in client mode, because I don't see any -D definition, so the default applies. So, milter delivers mail back to postfix for final delivery? 1. does amavisd-new listen on port 10028? Yes. 2. IIUC FILTER applies after message is queued - after milter was applied. Testing shows you are right, please read on. again, FILTER applies after mail is received, so next lines in log should show how the mail is delivered to amavis on port 10028 Next lines show that the mail is quarantined (it is an EICAR virus-test message, which should be quarantined if it does not by-pass through port 10028, as desired); here is the whole session: Feb 8 01:54:53 mailgw1 postfix/smtpd[202464]: connect from hedgehog.birch.relay.mailchannels.net[23.83.209.81] Feb 8 01:54:54 mailgw1 postfix/smtpd[202464]: Anonymous TLS connection established from hedgehog.birch.relay.mailchannels.net[23.83.209.81]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Feb 8 01:54:55 mailgw1 postfix/smtpd[202464]: NOQUEUE: filter: RCPT from hedgehog.birch.relay.mailchannels.net[23.83.209.81]: : Sender address triggers FILTER smtp:[127.0.0.1]:10028; from= to= proto=ESMTP helo= Feb 8 01:54:55 mailgw1 postfix/smtpd[202464]: 4DYmH36X5JzLlrw: client=hedgehog.birch.relay.mailchannels.net[23.83.209.81] Feb 8 01:54:56 mailgw1 postfix/cleanup[202468]: 4DYmH36X5JzLlrw: message-id=<464576df-43d0-ecac-5647-99c91a95c...@example.com> Feb 8 01:54:56 mailgw1 postfix/cleanup[202468]: 4DYmH36X5JzLlrw: milter-discard: END-OF-MESSAGE from hedgehog.birch.relay.mailchannels.net[23.83.209.81]: milter triggers DISCARD action; from= to= proto=ESMTP helo= Feb 8 01:54:56 mailgw1 postfix/smtpd[202464]: disconnect from hedgehog.birch.relay.mailchannels.net[23.83.209.81] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 The message is not honoring the bypass and gets quarantined. But if I don't send an infected message, the flow is clearer: First the message is delivered via the milter, scanned via the normal policy bank, and only AFTER that it is examined by the BYPASS policy bank! Here is a log: Feb 8 15:15:00 mailgw1 postfix/smtpd[219538]: connect from black.elm.relay.mailchannels.net[23.83.212.19] Feb 8 15:15:01 mailgw1 postfix/smtpd[219538]: Anonymous TLS connection established from black.elm.relay.mailchannels.net[23.83.212.19]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Feb 8 15:15:03 mailgw1 postfix/smtpd[219538]: NOQUEUE: filter: RCPT from black.elm.relay.mailchannels.net[23.83.212.19]: : Sender address triggers FILTER smtp:[127.0.0.1]:10028; from= to= proto=ESMTP helo= Feb 8 15:15:03 mailgw1 postfix/smtpd[219538]: 4DZ62H32SKzLm4t: client=black.elm.relay.mailchannels.net[23.83.212.19] Feb 8 15:15:04 mailgw1 postfix/cleanup[219533]: 4DZ62H32SKzLm4t: message-id=<3692cf3d-0de8-fe26-4541-c5876658b...@example.com> Feb 8 15:15:04 mailgw1 postfix/qmgr[202450]: 4DZ62H32SKzLm4t: from=, size=2167, nrcpt=1 (queue active) Feb 8 15:15:04 mailgw1 postfix/smtpd[219538]: disconnect from black.elm.relay.mailchannels.net[23.83.212.19] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 Feb 8 15:15:04 mailgw1 postfix/smtp[219543]: 4DZ62H32SKzLm4t: to=, relay=127.0.0.1[127.0.0.1]:10028, delay=2.1, delays=1.7/0.03/0.06/0.39, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4DZ62J63CZzLm4w) Feb 8 15:15:04 mailgw1 postfix/qmgr[202450]: 4DZ62H32SKzLm4t: removed and in Amavis: Feb 8 15:15:04 mailgw1 amavis[219136]: loaded policy bank "AM.PDP-SOCK" Feb 8 15:15:04 mailgw1 amavis[219136]: process_request: fileno sock=19, STDIN=0, STDOUT=1 Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: request=AM.PDP Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: queue_id=4DZ62H32SKzLm4t Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: sender= Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: recipient= Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: tempdir=/var/spool/amavisd/tmp/afO7JePJ Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: tempdir_removed_by=client Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: mail_file=/var/spool/amavisd/tmp/afO7JePJ/email.txt Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: delivery_care_of=client Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: client_address=23.83.212.19 Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: client_name=black.elm.relay.mailchannels.net Feb 8 15:15:04 mailgw1 amavis[219136]: policy protocol: helo_name=black.elm.relay.mailchannels.ne
Re: postscreen
On 08.02.2021 14:50, Matus UHLAR - fantomas wrote: > On 08.02.21 14:48, maciejm wrote: >> What I must set to enable "postscreen" ? > > it's described on: > http://www.postfix.org/POSTSCREEN_README.html > >> I ask because I must use "-o >> receive_override_options=no_address_mappings" in master.cf > > no, you usually don't have to do this, it should usually be used when > receiving mail from content filter. > I realy known what I need I have many alias group and others and this options I need (amavis+SA+other) and works perfectly. >> smtp inet n - y - 100 smtpd >> -o receive_override_options=no_address_mappings >> ... >> proxymap unix - - n - - proxymap >> proxywrite unix - - n - 1 proxymap >> smtp unix - - y - - smtp >> -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 >> ... >
Re: postscreen
On 08.02.21 14:48, maciejm wrote: What I must set to enable "postscreen" ? it's described on: http://www.postfix.org/POSTSCREEN_README.html I ask because I must use "-o receive_override_options=no_address_mappings" in master.cf no, you usually don't have to do this, it should usually be used when receiving mail from content filter. smtp inet n - y - 100 smtpd -o receive_override_options=no_address_mappings ... proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - y - - smtp -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 ... -- 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. Boost your system's speed by 500% - DEL C:\WINDOWS\*.*
postscreen
Hello What I must set to enable "postscreen" ? I ask because I must use "-o receive_override_options=no_address_mappings" in master.cf smtp inet n - y - 100 smtpd -o receive_override_options=no_address_mappings ... proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - y - - smtp -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 ...
Re: TCP wrappers and Postfix
On 08.02.21 16:27, Eugene Podshivalov wrote: Have read through the postscreen documentation closely and got it setup and running already, but could not find the three major possibilities provided by the tcp wrappers: 1. block by hostname 2. block clients with unknown hostname 3. block clients with invalid address<->name mapping The last two produce the major bulk of spambot connections. Are there any other means to achieve these? you can block these at smtpd level. Postscreen doesn't (and won't) check for reverse hostname. -- 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. "The box said 'Requires Windows 95 or better', so I bought a Macintosh".
Re: User script for modifying main.cf and other config files
On 07 Feb 2021, at 08:54, Alex wrote: > I'm working on a front-end to modify our main.cf and other config > files, such as the transport and relay_recips file and want to be sure > I'm doing it securely. Use a tool like Webmin¹. It is, in my opinion a very very bad idea, but the way to do this outside of an admin shell session is through an admin panel. For user management, including admin access to hosted domains, a tool like postfixadmin seems to work pretty well. That said, if you have an admin interface like webmin or postfixadmin you need to be very conscious of keeping these tools up-to-date as they are frequent targets of attack. > Postfix complains if the files are not owned by root, but I don't want > the script to have to run as root. What is the most secure way to do > this? Definitely not via a automated script that takes user submission and changes your mail config. Even allowing access to files that you may think are OK (virtual or aliases, perhaps?) can be disastrous. > Perhaps passwordless sudo with the explicit ability to act on these > files and reload/restart postfix? Is it okay to create a backup > directory in /etc/postfix that's owned by this script user? I wonder what changes you need to make so frequently. Whatever they are, stop and reconsider. There is no scenario where allowing users to alter your mail config could be considered secure. I do have one script that generates a postfix config file, but it is entirely automated and writes a daily bcc file. Even though it is very simple, I ran it by this list in case I'd overlooked something very stupid. It's been running for over 4 years now so I'm /relatively/ confident there's nothing wrong with it. ¹ I am not specifically recommending webmin, I do not run it and I wold not run it as I prefer accessing my server via ssh with a key exchange which can only be duplicated if someone gets my private key file off my home machine, or if someone can login to the console on-site as me. -- "Are you pondering what I'm pondering?" "I think so, Brain, but shouldn't the bat boy be wearing a cape?"
Re: TCP wrappers and Postfix
Have read through the postscreen documentation closely and got it setup and running already, but could not find the three major possibilities provided by the tcp wrappers: 1. block by hostname 2. block clients with unknown hostname 3. block clients with invalid address<->name mapping The last two produce the major bulk of spambot connections. Are there any other means to achieve these? пн, 8 февр. 2021 г. в 12:14, Eugene Podshivalov : > I'm new to postscreen and it's what I was looking for. Thanks a lot for > the answers! > > пн, 8 февр. 2021 г. в 11:22, Dominic Raferd : > >> On 08/02/2021 08:04, Eugene Podshivalov wrote: >> > There are a bunch of spiders and spammers nowadays which are knocking >> > the service every hour or so every day. Postfix has a really powerful >> > access control system to protect itself but it becomes a bit hard to >> > read the log file flooded by the connection attempts. I'm currently >> > trying to filter those out by UFW but dynamic addresses make it quite >> > inefficient. >> >> My 2p (I also use ufw but as a last-resort): >> >> Postscreen of course >> >> Fail2ban 0.10+ with its postfix (and recidive) jails >> >> If you run postfix's dnsblog you could remove it to reduce the number of >> log entries >> >> If you allow incoming emails by IPv6 you might turn it off >> >>
Re: Stucked with "unable to look up host"
On 31.01.21 09:56, Daniel Armando Rodriguez wrote: Indeed, it was running chrooted but resolv.conf has the same content === # postconf -nf smtp_tls_protocols = TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3 this is superflous and not a good idea. Many servers support TLS1.0 max. !SSLv2, !SSLv3 should be enough for now. After adjusting values the recommended way not getting connect to correo.dominio.com.ar[]:25: Connection timed out % host -t any correo.dominio.com.ar Host correo.dominio.com.ar not found: 3(NXDOMAIN) correo.dominio.com.ar does not exist, so you can't send mail there. It is also reason why it was not resolved. and Jan 31 09:43:42 domiinio postfix/smtp[13099]: Untrusted TLS connection established to alt2.gmail-smtp-in.l.google.com[172.217.218.26]:25: TLSv1.2 with cipher ECDHE-ECDSA-CHACHA20-POLY1305 (256/256 bits) Jan 31 09:43:42 dominio postfix/smtp[13099]: E6AA880124FF7: to=< u...@gmail.com>, relay=alt2.gmail-smtp-in.l.google.com[172.217.218.26]:25, delay=40220, delays=40215/0/4.5/0, dsn=4.7.5, status=deferred (Server certificate not trusted) This is caused by your setting: smtp_tls_security_level = verify smtp, by default, is plaintext, and encryption is not fully standard, so you disable sending mail to part of internet. -- 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. Silvester Stallone: Father of the RISC concept.
Re: Communication between postfix - amavis issues
On 08.02.21 12:47, Nikolaos Milas wrote: We have a mail gateway server (for incoming email) with postfix 3.5.8, amavisd, clamd on CentOS 8.3.2011. Postfix sends incoming mail to amavisd via (in main.cf): smtpd_milters = unix:/run/amavisd/amavisd-milter.sock After checking, amavisd delivers mail directly using amavisd-milter daemon. that's not how milter works, unless you instructed amavisd-milter to deliver mail by server via "-D server" option. The default is "-D client", which means, amavisd instructs postfix what to do with the mail - reject/quarantine/pass it, add/remove/modify the headers etc. My problem is that under our current setup it seems that amavisd will not receive mail to port 10028 (used as a bypass, to disable all scanning), although it is listening. How should I modify postfix config so that it sends successfully mail to port 10028 as configured? 1. does amavisd-new listen on port 10028? 2. IIUC FILTER applies after message is queued - after milter was applied. I am trying the following mechanism to bypass amavisd scans for particular senders: smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/amavis_bypass_senders ... /etc/postfix/amavis_bypass_senders: us...@example.com FILTER smtp:[127.0.0.1]:10028 us...@example.com FILTER smtp:[127.0.0.1]:10028 However, the amavis policy bank listening at 10028 is never triggered. The log states: ... Feb 8 01:54:55 mailgw1 postfix/smtpd[202464]: NOQUEUE: filter: RCPT from hedgehog.birch.relay.mailchannels.net[23.83.209.81]: : Sender address triggers FILTER smtp:[127.0.0.1]:10028; from= to= proto=ESMTP helo= Feb 8 01:54:55 mailgw1 postfix/smtpd[202464]: 4DYmH36X5JzLlrw: client=hedgehog.birch.relay.mailchannels.net[23.83.209.81] Feb 8 01:54:56 mailgw1 postfix/cleanup[202468]: 4DYmH36X5JzLlrw: message-id=<464576df-43d0-ecac-5647-99c91a95c...@example.com> ... again, FILTER applies after mail is received, so next lines in log should show how the mail is delivered to amavis on port 10028 -- 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. Honk if you love peace and quiet.
Communication between postfix - amavis issues
Hello, We have a mail gateway server (for incoming email) with postfix 3.5.8, amavisd, clamd on CentOS 8.3.2011. Postfix sends incoming mail to amavisd via (in main.cf): smtpd_milters = unix:/run/amavisd/amavisd-milter.sock After checking, amavisd delivers mail directly using amavisd-milter daemon. My problem is that under our current setup it seems that amavisd will not receive mail to port 10028 (used as a bypass, to disable all scanning), although it is listening. How should I modify postfix config so that it sends successfully mail to port 10028 as configured? I am trying the following mechanism to bypass amavisd scans for particular senders: smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/amavis_bypass_senders ... /etc/postfix/amavis_bypass_senders: us...@example.com FILTER smtp:[127.0.0.1]:10028 us...@example.com FILTER smtp:[127.0.0.1]:10028 However, the amavis policy bank listening at 10028 is never triggered. The log states: ... Feb 8 01:54:55 mailgw1 postfix/smtpd[202464]: NOQUEUE: filter: RCPT from hedgehog.birch.relay.mailchannels.net[23.83.209.81]: : Sender address triggers FILTER smtp:[127.0.0.1]:10028; from= to= proto=ESMTP helo= Feb 8 01:54:55 mailgw1 postfix/smtpd[202464]: 4DYmH36X5JzLlrw: client=hedgehog.birch.relay.mailchannels.net[23.83.209.81] Feb 8 01:54:56 mailgw1 postfix/cleanup[202468]: 4DYmH36X5JzLlrw: message-id=<464576df-43d0-ecac-5647-99c91a95c...@example.com> ... I also tried with: us...@example.com FILTER smtp-amavis:[127.0.0.1]:10028 us...@example.com FILTER smtp-amavis:[127.0.0.1]:10028 which produced the same results. What am I doing wrong? My master.cf is as follows: # == # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # == #smtp inet n - n - - smtpd -v smtp inet n - n - 1 postscreen smtpd pass - - n - - smtpd dnsblog unix - - n - 0 dnsblog tlsproxy unix - - n - 0 tlsproxy pickup fifo n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr #qmgr fifo n - n 300 1 oqmgr tlsmgr unix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounce unix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verify unix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap smtp unix - - n - - smtp # When relaying mail as backup MX, disable fallback_relay to avoid MX loops relay unix - - n - - smtp -o smtp_fallback_relay= # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 showq unix n - n - - showq error unix - - n - - error discard unix - - n - - discard local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil scache unix - - n - 1 scache retry unix - - n - - error proxywrite unix - - n - 1 proxymap smtp-amavis unix - - n - 2 lmtp -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes -o disable_dns_lookups=yes -o max_use=20 127.0.0.1:10025 inet n - n - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipien
Re: fork_attempts=10 ?
:-) On 2/7/21 11:29 PM, Bob Proulx wrote: Marek Kozlowski wrote: No, such configurable limits are great. My question was different. I suppose that many many years ago, many versions ago I had some problem with this server and I tried to solve it or apply a quick fix by incrementing the limit. Unfortunately I don't remember the problem. I don't even know if it could reappear if I set it to the default. Can anyone guess the potential problem given the solution? ;-)) I think if you were increasing the fork_attempts value that as Wietse noted your system was overloaded. And the root cause of the problem was elsewhere in the system. But to help understand your question specifically it is needed to understand fork() and why it might fail. > [...] No, I perfectly know what the fork() syscall does. The question is different. I believe and my experience proves that the default values for limits and similar parameters set by Venema are chosen carefully and intentionally and in typical use / most cases are optimal or - at least - more than satisfactory (that is: provide stable, safe and efficient work). My system is not overloaded and - in many aspects quite typical one. If I had to double some value something very strange must have occurred. I'm wondering what was it (a black hole in my memory). Best regards, Marek smime.p7s Description: S/MIME Cryptographic Signature
Re: TCP wrappers and Postfix
I'm new to postscreen and it's what I was looking for. Thanks a lot for the answers! пн, 8 февр. 2021 г. в 11:22, Dominic Raferd : > On 08/02/2021 08:04, Eugene Podshivalov wrote: > > There are a bunch of spiders and spammers nowadays which are knocking > > the service every hour or so every day. Postfix has a really powerful > > access control system to protect itself but it becomes a bit hard to > > read the log file flooded by the connection attempts. I'm currently > > trying to filter those out by UFW but dynamic addresses make it quite > > inefficient. > > My 2p (I also use ufw but as a last-resort): > > Postscreen of course > > Fail2ban 0.10+ with its postfix (and recidive) jails > > If you run postfix's dnsblog you could remove it to reduce the number of > log entries > > If you allow incoming emails by IPv6 you might turn it off > >
Re: TCP wrappers and Postfix
On 08/02/2021 08:04, Eugene Podshivalov wrote: There are a bunch of spiders and spammers nowadays which are knocking the service every hour or so every day. Postfix has a really powerful access control system to protect itself but it becomes a bit hard to read the log file flooded by the connection attempts. I'm currently trying to filter those out by UFW but dynamic addresses make it quite inefficient. My 2p (I also use ufw but as a last-resort): Postscreen of course Fail2ban 0.10+ with its postfix (and recidive) jails If you run postfix's dnsblog you could remove it to reduce the number of log entries If you allow incoming emails by IPv6 you might turn it off
Re: TCP wrappers and Postfix
There are a bunch of spiders and spammers nowadays which are knocking the service every hour or so every day. Postfix has a really powerful access control system to protect itself but it becomes a bit hard to read the log file flooded by the connection attempts. I'm currently trying to filter those out by UFW but dynamic addresses make it quite inefficient. Regards, Eugene пн, 8 февр. 2021 г. в 04:01, Viktor Dukhovni : > On Mon, Feb 08, 2021 at 02:17:46AM +0300, Eugene Podshivalov wrote: > > > Are there any reasons not to have Postfix compiled with TCP wrappers? > > Because that would likely be entirely redundant. Postfix already has > IP-based access controls (local tables, RBL lookups, postscreen(8), ... > and can also log additional message envelope details before rejecting > connections. > > As Wietse is the author of both TCP wrappers and Postfix, if there were > any cause to build TCP wrappers into Postfix, he'd probably have done > it long ago. > > -- > Viktor. >
