Re: logging directly to database?
On 22.09.21 04:26, Alex wrote: Yes, thanks. I realize I can do that - it's the "your_script_that_saves_to_sql" part that would be very helpful :-) Not sure if there's a one-size-fits-all script that works in all setups, it's going to be highly individualized. > There's also great difficulty with correlating log lines from > postscreen, smtpd. local, etc, and tracing all of the processes from > the initial CONNECT through to the eventual delivery. We ended up using the queue ID for our log analyzer, but that is only assigned one step after CONNECT. Other than that it works reasonably well tho, rspamd and cyrus use it as well, so we can track it through our whole stack. OpenPGP_signature Description: OpenPGP digital signature
Re: logging directly to database?
On Wed, Sep 22, 2021 at 10:15:50AM +0200, Sven Schwedas wrote: > On 22.09.21 04:26, Alex wrote: > > Yes, thanks. I realize I can do that - it's the > > "your_script_that_saves_to_sql" part that would be very helpful :-) > > Not sure if there's a one-size-fits-all script that works in all setups, > it's going to be highly individualized. > > > There's also great difficulty with correlating log lines from > > postscreen, smtpd. local, etc, and tracing all of the processes from > > the initial CONNECT through to the eventual delivery. > > We ended up using the queue ID for our log analyzer, but that is only > assigned one step after CONNECT. Other than that it works reasonably well > tho, rspamd and cyrus use it as well, so we can track it through our whole > stack. On that note, you'll probably want to set enable_long_queue_ids = yes. It ensures that queue IDs are unique/non-repeating so that log analysis doesn't get mislead. http://www.postfix.org/postconf.5.html#enable_long_queue_ids cheers, raf
Wierd behaviour: postconf -xd proxy_read_maps
Hi, I just encountered a wierd thing (debian-11 stable, postfix-3.5.6-1+b1). I ran: $ postconf -df proxy_read_maps proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $smtpd_sender_login_maps $sender_bcc_maps $recipient_bcc_maps $smtp_generic_maps $lmtp_generic_maps $alias_maps $smtpd_client_restrictions $smtpd_helo_restrictions $smtpd_sender_restrictions $smtpd_relay_restrictions $smtpd_recipient_restrictions $address_verify_sender_dependent_default_transport_maps $address_verify_sender_dependent_relayhost_maps $address_verify_transport_maps $fallback_transport_maps $lmtp_discard_lhlo_keyword_address_maps $lmtp_pix_workaround_maps $lmtp_sasl_password_maps $lmtp_tls_policy_maps $mailbox_command_maps $mailbox_transport_maps $postscreen_discard_ehlo_keyword_address_maps $rbl_reply_maps $sender_dependent_default_transport_maps $sender_dependent_relayhost_maps $smtp_discard_ehlo_keyword_address_maps $smtp_pix_workaround_maps $smtp_sasl_password_maps $smtp_tls_policy_maps $smtpd_discard_ehlo_keyword_address_maps $smtpd_milter_maps $virtual_gid_maps $virtual_uid_maps And I thought I'd recursively expand all the items, but I didn't get what I expected. Here are the non-empty items individually expanded (redacted): local_recipient_maps = proxy:unix:passwd.byname hash:/etc/aliases, nis:mail.aliases mydestination = hostname.localdomain, localhost.localdomain, localhost relay_domains = hostname.localdomain, localhost.localdomain, localhost mynetworks = 127.0.0.0/8 a.b.c.d/32 [::1]/128 [a:b:c:d::e]/128 [fe80::]/64 alias_maps = hash:/etc/aliases, nis:mail.aliases So I was expecting all of that concatenated: proxy_read_maps = proxy:unix:passwd.byname hash:/etc/aliases, nis:mail.aliases hostname.localdomain, localhost.localdomain, localhost hostname.localdomain, localhost.localdomain, localhost 127.0.0.0/8 a.b.c.d/32 [::1]/128 [a:b:c:d::e]/128 [fe80::]/64 hash:/etc/aliases, nis:mail.aliases But instead I saw: $ postconf -xdf proxy_read_maps proxy_read_maps = all127.0.0.0/8 a.b.c.d/32 [::1]/128 [a:b:c:d::e]/128 [fe80::]/64 hash:/etc/aliases, nis:mail.aliases It looks like the default value of inet_interfaces or inet_protocols "all" (neither of which belong there), immediately followed (with no intervening space) by the default values of mynetworks and alias_maps. Where did the "all" come from? What happened to the default values of local_recipient_maps, mydestination and relay_domains? This happens with or without the -f option. Does it happen with a non-Debian-packaged version? If anyone can explain this behaviour, or the error in my expectations, that would be great. Without the -d option for defaults, the output is perfect. cheers, raf
Re: Patch: Wierd behaviour: postconf -xd proxy_read_maps
On Wed, Sep 22, 2021 at 10:35:45PM +1000, raf wrote:
> I just encountered a wierd thing (debian-11 stable, postfix-3.5.6-1+b1).
Thanks for the bug report.
> $ postconf -xdf proxy_read_maps
> proxy_read_maps = all127.0.0.0/8 a.b.c.d/32 [::1]/128
>[a:b:c:d::e]/128 [fe80::]/64 hash:/etc/aliases, nis:mail.aliases
The problem is an recursive reuse of a static buffer in the postconf(1)
code (does not affect any other Postfix programs, ...) that expands the
default value of mynetworks, when called recursively from expanding some
other parameter.
Patch below.
--
Viktor.
--- a/src/postconf/postconf_builtin.c
+++ b/src/postconf/postconf_builtin.c
@@ -250,6 +250,7 @@ static const char *pcf_check_mydomainname(void)
static const char *pcf_mynetworks(void)
{
static const char *networks;
+static VSTRING *local_buf;
const char *junk;
/*
@@ -258,10 +259,13 @@ static const char *pcf_mynetworks(void)
if (networks)
return (networks);
+if (local_buf == 0)
+local_buf = vstring_alloc(100);
+
if (var_inet_interfaces == 0) {
if ((pcf_cmd_mode & PCF_SHOW_DEFS)
|| (junk = mail_conf_lookup_eval(VAR_INET_INTERFACES)) == 0)
- junk = pcf_expand_parameter_value((VSTRING *) 0, pcf_cmd_mode,
+ junk = pcf_expand_parameter_value(local_buf, pcf_cmd_mode,
DEF_INET_INTERFACES,
(PCF_MASTER_ENT *) 0);
var_inet_interfaces = mystrdup(junk);
@@ -269,7 +273,7 @@ static const char *pcf_mynetworks(void)
if (var_mynetworks_style == 0) {
if ((pcf_cmd_mode & PCF_SHOW_DEFS)
|| (junk = mail_conf_lookup_eval(VAR_MYNETWORKS_STYLE)) == 0)
- junk = pcf_expand_parameter_value((VSTRING *) 0, pcf_cmd_mode,
+ junk = pcf_expand_parameter_value(local_buf, pcf_cmd_mode,
DEF_MYNETWORKS_STYLE,
(PCF_MASTER_ENT *) 0);
var_mynetworks_style = mystrdup(junk);
@@ -277,7 +281,7 @@ static const char *pcf_mynetworks(void)
if (var_inet_protocols == 0) {
if ((pcf_cmd_mode & PCF_SHOW_DEFS)
|| (junk = mail_conf_lookup_eval(VAR_INET_PROTOCOLS)) == 0)
- junk = pcf_expand_parameter_value((VSTRING *) 0, pcf_cmd_mode,
+ junk = pcf_expand_parameter_value(local_buf, pcf_cmd_mode,
DEF_INET_PROTOCOLS,
(PCF_MASTER_ENT *) 0);
var_inet_protocols = mystrdup(junk);
Re: tlsmgr timeout
Hi, > > Can someone help me troubleshoot why I'm periodically receiving these > > messages? It results in postfix stop responding to connections > > altogether. > > > > Sep 21 19:18:41 xavier postfix-116/smtpd[2485484]: warning: problem > > talking to server private/tlsmgr: Connection timed out > > Sep 21 19:25:38 xavier postfix-117/smtpd[2491054]: warning: problem > > talking to server private/tlsmgr: Connection timed out > > What databases if any are using for TLS session caches? Are any > of the instances inadvertently sharing their TLS session caches > databases? Yes, that's probably what's happening. > smtp_tls_session_cache_database This is undefined for all instances. > smtpd_tls_session_cache_database This is defined to the default for all instances: smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache > Also, what is the configure random source, and what OS? > > tls_random_source This is fedora34: tls_random_source = dev:/dev/urandom Thanks, Alex
Re: tlsmgr timeout
> On 22 Sep 2021, at 1:11 pm, Alex wrote:
>
>>smtpd_tls_session_cache_database
>
> This is defined to the default for all instances:
> smtpd_tls_session_cache_database =
> btree:/var/lib/postfix/smtpd_tls_session_cache
That's wrong. The session cache needs to be:
smtpd_tls_session_cache_database = ${data_directory}/smtpd_tls_session_cache
with (enforced by postmulti) distict values of `data_directory`
for each instance. Only the default instance gets to scribble
in "/var/lib/postfix".
--
Viktor.
Re: Patch: Wierd behaviour: postconf -xd proxy_read_maps
Viktor Dukhovni:
> On Wed, Sep 22, 2021 at 10:35:45PM +1000, raf wrote:
>
> > I just encountered a wierd thing (debian-11 stable, postfix-3.5.6-1+b1).
>
> Thanks for the bug report.
>
> > $ postconf -xdf proxy_read_maps
> > proxy_read_maps = all127.0.0.0/8 a.b.c.d/32 [::1]/128
> >[a:b:c:d::e]/128 [fe80::]/64 hash:/etc/aliases, nis:mail.aliases
>
> The problem is an recursive reuse of a static buffer in the postconf(1)
> code (does not affect any other Postfix programs, ...) that expands the
> default value of mynetworks, when called recursively from expanding some
> other parameter.
>
> Patch below.
Thanks. This is the result of lazy coding in a nasty language.
I should stop hidden static buffers, or switch to a language
has automatic destructors like C++ or Go.
Wietse
> --
> Viktor.
>
> --- a/src/postconf/postconf_builtin.c
> +++ b/src/postconf/postconf_builtin.c
> @@ -250,6 +250,7 @@ static const char *pcf_check_mydomainname(void)
> static const char *pcf_mynetworks(void)
> {
> static const char *networks;
> +static VSTRING *local_buf;
> const char *junk;
>
> /*
> @@ -258,10 +259,13 @@ static const char *pcf_mynetworks(void)
> if (networks)
> return (networks);
>
> +if (local_buf == 0)
> +local_buf = vstring_alloc(100);
> +
> if (var_inet_interfaces == 0) {
> if ((pcf_cmd_mode & PCF_SHOW_DEFS)
> || (junk = mail_conf_lookup_eval(VAR_INET_INTERFACES)) == 0)
> - junk = pcf_expand_parameter_value((VSTRING *) 0, pcf_cmd_mode,
> + junk = pcf_expand_parameter_value(local_buf, pcf_cmd_mode,
> DEF_INET_INTERFACES,
> (PCF_MASTER_ENT *) 0);
> var_inet_interfaces = mystrdup(junk);
> @@ -269,7 +273,7 @@ static const char *pcf_mynetworks(void)
> if (var_mynetworks_style == 0) {
> if ((pcf_cmd_mode & PCF_SHOW_DEFS)
> || (junk = mail_conf_lookup_eval(VAR_MYNETWORKS_STYLE)) == 0)
> - junk = pcf_expand_parameter_value((VSTRING *) 0, pcf_cmd_mode,
> + junk = pcf_expand_parameter_value(local_buf, pcf_cmd_mode,
> DEF_MYNETWORKS_STYLE,
> (PCF_MASTER_ENT *) 0);
> var_mynetworks_style = mystrdup(junk);
> @@ -277,7 +281,7 @@ static const char *pcf_mynetworks(void)
> if (var_inet_protocols == 0) {
> if ((pcf_cmd_mode & PCF_SHOW_DEFS)
> || (junk = mail_conf_lookup_eval(VAR_INET_PROTOCOLS)) == 0)
> - junk = pcf_expand_parameter_value((VSTRING *) 0, pcf_cmd_mode,
> + junk = pcf_expand_parameter_value(local_buf, pcf_cmd_mode,
> DEF_INET_PROTOCOLS,
> (PCF_MASTER_ENT *) 0);
> var_inet_protocols = mystrdup(junk);
>
Re: Patch: Wierd behaviour: postconf -xd proxy_read_maps
On Wed, Sep 22, 2021 at 12:56:30PM -0400, Viktor Dukhovni wrote: > On Wed, Sep 22, 2021 at 10:35:45PM +1000, raf wrote: > > > I just encountered a wierd thing (debian-11 stable, postfix-3.5.6-1+b1). > > Thanks for the bug report. Thanks for the fix!
Re: Patch: Wierd behaviour: postconf -xd proxy_read_maps
On Wed, Sep 22, 2021 at 07:11:19PM -0400, Wietse Venema wrote: > Viktor Dukhovni: > > On Wed, Sep 22, 2021 at 10:35:45PM +1000, raf wrote: > > > > > I just encountered a wierd thing (debian-11 stable, postfix-3.5.6-1+b1). > > > > Thanks for the bug report. > > > > > $ postconf -xdf proxy_read_maps > > > proxy_read_maps = all127.0.0.0/8 a.b.c.d/32 [::1]/128 > > >[a:b:c:d::e]/128 [fe80::]/64 hash:/etc/aliases, nis:mail.aliases > > > > The problem is an recursive reuse of a static buffer in the postconf(1) > > code (does not affect any other Postfix programs, ...) that expands the > > default value of mynetworks, when called recursively from expanding some > > other parameter. > > > > Patch below. > > Thanks. This is the result of lazy coding in a nasty language. > I should stop hidden static buffers, or switch to a language > has automatic destructors like C++ or Go. > > Wietse or Rust! :-) cheers, raf
Re: AW: Spam pass the filter
On 2021-09-18 6:10 p.m., Christian Schmitz wrote: On Saturday 18 September 2021 10:13:41 ludic...@gmail.com wrote: Hi, pcre header checks we use. Not all the time, depends on spam volume from these valuable enterprises. #/sjmedia.us/ REJECT A mass mail service abused by criminals #/bmsend.com/ REJECT A mass mail service abused by criminals #/mailgun.net/ REJECT A mass mail service abused by criminals #/rsgsv.net/REJECT A mass mail service abused by criminals #/mcsv.net/ REJECT A mass mail service abused by criminals #/sendgrid.net/ REJECT A mass mail service abused by criminals #/crsend.com/ REJECT A mass mail service abused by criminals #/zcsend.net/ REJECT A mass mail service abused by criminals I forgot if all those can be catched by limiting it to the Received-Line. Greets, Ludi -Ursprüngliche Nachricht- Von: owner-postfix-us...@postfix.org Im Auftrag von Christian Schmitz Gesendet: Freitag, 17. September 2021 14:41 An: postfix-users@postfix.org Betreff: Spam pass the filter Hi everyone: Normally when i identify a host spammer i block entire server. Today i receive one spam email. The origin is "mailgun.net", i already have a rule to block him, but the email pass with no problem. I want stop the email, what is wrong? The header, config and rules are the following. Best Regards and thanks in advance Christian Thanks to all. I do not use spamassasin since the spam and mail level is too low in my server ( 2~5 emails at day). I take the policy of block entire spammer mail server. I will read and adapt my rules. Thanks to everyone. Christian Hi Christian, It's still worth running SpamAssassin on a low volume server. You are correct that you will not have enough spam to train Bayes but SpamAssassin ships with rules that can catch spam based on regex's, DNSBL queries and do forth. It's also a handy platform for writing your own site-specific rules, which also function in the absence of Bayes. - J
Re: Spam pass the filter
On 04:41 PM 17-Sep-21, Benny Pedersen wrote: On 2021-09-17 14:40, Christian Schmitz wrote: make a spamassassin rule to check dkim, make that dkim score 1000, if you reject high score spam there is nothing more to do In this day and age rspamd is much better. -- Gayatri Hitech, www.spamcheetah.com Skype: girish1729 Mobile: +91-9080084016
Re: Patch: Wierd behaviour: postconf -xd proxy_read_maps
On Thu, Sep 23, 2021 at 09:28:59AM +1000, raf wrote: > > Thanks. This is the result of lazy coding in a nasty language. > > I should stop hidden static buffers, or switch to a language > > has automatic destructors like C++ or Go. > > > > Wietse > > or Rust! :-) We all have our favourite much safer than C compiled languages. Rust is not a bad choice for avoiding mutable shared data, my choice in that space these days is Haskell. Pity Wietse and I are unlikely to find a better that C we're both presently comfortable in. Migration away from C is not an urgent problem in Postfix, as you probably know. Thanks to Wietse's diligence, C footguns are exceedingly rare in Postfix. This one creates no notable issues, just returns an incorrect answer from some "postconf -xd" recursive expansions. -- Viktor.
Re: Patch: Wierd behaviour: postconf -xd proxy_read_maps
On Wed, Sep 22, 2021 at 10:52:02PM -0400, Viktor Dukhovni wrote: > On Thu, Sep 23, 2021 at 09:28:59AM +1000, raf wrote: > > > > Thanks. This is the result of lazy coding in a nasty language. > > > I should stop hidden static buffers, or switch to a language > > > has automatic destructors like C++ or Go. > > > > > > Wietse > > > > or Rust! :-) > > We all have our favourite much safer than C compiled languages. Rust is > not a bad choice for avoiding mutable shared data, my choice in that > space these days is Haskell. Pity Wietse and I are unlikely to find a > better C that we're both presently comfortable in. > > Migration away from C is not an urgent problem in Postfix, as you > probably know. Thanks to Wietse's diligence, C footguns are exceedingly > rare in Postfix. This one creates no notable issues, just returns an > incorrect answer from some "postconf -xd" recursive expansions. > > -- > Viktor. Yes. In Postfix's case, migration away from C would be a huge investment with very little return (no matter how lovely other languages might be). I'm happy as long as "postconf -x" works (without -d) in existing versions, and that looks fine. cheers, raf
Re: Spam pass the filter
On 23/9/2021 10:34 am, Girish Venkatachalam wrote: In this day and age rspamd is much better. I second that. P.V.Anthony
