[pfx] Re: sendmail bounce messages
As always, very grateful for your clarifications. El 8/6/23 a las 18:12, Wietse Venema via Postfix-users escribió: Wietse Venema via Postfix-users: Victor Rubiella Monfort via Postfix-users: Hi, I want to prevent that sendmail milter rejections generates bounces messages. Reading sendmail documentation I see "-N" option: echo "HELLO" | sendmail -N 'never' t...@test.es; echo $? 0 Jun 8 13:51:30 server.test postfix/cleanup[597560]: 077616620F: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 5.7.1 Rejected for policy reason; from= to= Jun 8 13:51:30 server.test postfix/cleanup[597560]: 077616620F: to=, relay=none, delay=0.1, delays=0.1/0/0/0, dsn=5.7.1, status=bounced (Rejected for policy reason) non-delivery notification seems not executed (no logs related). But logs shows as "status=bounced". This generate confusions on post-log-anilisis. I can prenvent this "status=bounced" on logs (status=rejected)? This is not configurable. Perhaps your log analyzer could look for messages that do not have an : sender non-delivery notification: record. Those messages were not returned to the sender. Note that "sendmail -N" (and NOTIFY=NONE in RCPT TO comands) disable sender notifications only, not postmaster notifications. Those are configured with main.cf:notify_classes, and produce similar logging: : postmaster non-delivery notification: When Postfix logs the status= value, it logs 'bounced' for compatibility with logfile analyzers that were written when Postfix had no support to disable sender non-delivery notifications. Postfix 'status=' logging was inspred by RFC 3461, which uses 'failed' in non-delivery status notifications. I suppose that here there could be a parameter setting to log 'failed' instead of 'bounced'. I would not log the REASON in the status= field; the reason is logged in the text portion in the logfile record. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] sendmail bounce messages
Hi, I want to prevent that sendmail milter rejections generates bounces messages. Reading sendmail documentation I see "-N" option: echo "HELLO" | sendmail -N 'never' t...@test.es; echo $? 0 Jun 8 13:51:30 server.test postfix/cleanup[597560]: 077616620F: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 5.7.1 Rejected for policy reason; from= to= Jun 8 13:51:30 server.test postfix/cleanup[597560]: 077616620F: to=, relay=none, delay=0.1, delays=0.1/0/0/0, dsn=5.7.1, status=bounced (Rejected for policy reason) non-delivery notification seems not executed (no logs related). But logs shows as "status=bounced". This generate confusions on post-log-anilisis. I can prenvent this "status=bounced" on logs (status=rejected)? Thanks! ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: logging strangeness
Hi, But what about show user login? Currently we have issues when fail2ban blocks IPS for a high number or failed logins, but is a customer with several mail accounts and he don't know which bad-configured account is causing the ban. Would be so healpfull shows the sasl_username that produces the failure. For example for imap/pop login failures dovecot log email account that produces the failure. El 16/5/23 a las 16:06, Wietse Venema via Postfix-users escribió: mailmary--- via Postfix-users: In all honesty, the current situation of logging the base64 string "UGFzc3dvcmQ6" does not help us. Maybe we could reconsider, and actually log the data (raw or base64-decoded)? Absolutely not. As a matter of security principle, one does not log the content of login failures unless absolutely necessary. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] temporary lookup error with utf8mb4 characters
Hi, I have more info and I try to explain it better:
First of all I have smtputf8_enable = no (disabled).
I have several databases related with several mysql_virtual maps:
- Some with utf8 + utf8_general_ci collation
- Another ones with latin1 + latin1_spanish_ci.
I'm using mysql-postfix (mysql_table) lookups, not postgres.
"proxy:mysql:/XXX.cf".
I can reproduce same issue with both cf files (tables with utf8 and
tables with latin1).
As I say before, the worst part is when error is raised during about 1
minute all lookups raises failures.
Error is easy to reproduce manually calling to "postmap -q
"emailWithspecialchar" "proxy:mysql:/XXX.cf"
Debugging I observe 2 things.
- adding CONVERT('%s' using ascii) fix the issue but I don't want/like
add converts on all my sql queries...
- adding COLLATE utf8_general_ci raises error "this collate is not valid
for utf8mb4". This error shows me than mysql_table lookup connections
are using "utf8mb4" charset by default.
My conclusion to hard-solve this issue on my system is transform all
tables to utf8mb4.
But:
- I don't see any option to change default charset on mysql_table
connector, maybe should be interesting add this option on configuration
file.
- mix collation error should raise 1 error, but next queries should be
work ok, this could be considered and issue right?.
- with "smtputf8_enable = no" I should be able to work without this kind
of issues right?
For modern protocols I can undestant change to utf8, but utf8mb4? this
is much more expensive for the database, is it really necessary?
El 14/4/23 a las 20:46, Viktor Dukhovni via Postfix-users escribió:
On Fri, Apr 14, 2023 at 01:06:16PM -0400, Wietse Venema via Postfix-users wrote:
Wietse Venema via Postfix-users:
As for the temp error becoming persistent, the Postfix pgsql: client
code returns an error when it gets an error from all of the hosts
configured in the Postfix pgsql: client configuration file, or when
all hosts have been flagged as 'down'. If a host returns an error
then the Postfix pgsql: client code flags that host as 'down', and
resets that 'down' state after about 60 seconds.
As implemented, the Postfix pgsql: clien code treats all errors as
a connection failure, and skips the connection for 60 seconds. That
may not be optimal when an error is data dependent.
FWIW, the OP's issue was with MySQL, not Postgres... The database
should be configured for client and server encoding of UTF8.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: temporary lookup error with utf8mb4 characters
Hi, I have more info and I try to explain it better:
First of all I have smtp_utf8 = no (disabled).
I have several databases related with several mysql_virtual maps:
- Some with utf8 + utf8_general_ci collation
- Another ones with latin1 + latin1_spanish_ci.
I'm using mysql-postfix (mysql_table) lookups, not postgres.
"proxy:mysql:/XXX.cf".
I can reproduce same issue with both cf files (tables with utf8 and
tables with latin1).
As I say before, the worst part is when error is raised during about 1
minute all lookups raises failures.
Error is easy to reproduce manually calling to "postmap -q
"emailWithspecialchar" "proxy:mysql:/XXX.cf"
Debugging I observe 2 things.
- adding CONVERT('%s' using ascii) fix the issue but I don't want/like
add converts on all my sql queries...
- adding COLLATE utf8_general_ci raises error "this collate is not valid
for utf8mb4". This error shows me than mysql_table lookup connections
are using "utf8mb4" charset by default.
My conclusion to hard-solve this issue on my system is transform all
tables to utf8mb4.
But:
- I don't see any option to change default charset on mysql_table
connector, maybe should be interesting add this option on configuration
file.
- mix collation error should raise 1 error, but next queries should be
work ok, this could be considered and issue right?.
- with "smtputf8_enable = no" I should be able to work without this kind
of issues right?
For modern protocols I can undestant change to utf8, but utf8mb4? this
is much more expensive for the database, is it really necessary?
**
El 14/4/23 a las 20:46, Viktor Dukhovni via Postfix-users escribió:
On Fri, Apr 14, 2023 at 01:06:16PM -0400, Wietse Venema via Postfix-users wrote:
Wietse Venema via Postfix-users:
As for the temp error becoming persistent, the Postfix pgsql: client
code returns an error when it gets an error from all of the hosts
configured in the Postfix pgsql: client configuration file, or when
all hosts have been flagged as 'down'. If a host returns an error
then the Postfix pgsql: client code flags that host as 'down', and
resets that 'down' state after about 60 seconds.
As implemented, the Postfix pgsql: clien code treats all errors as
a connection failure, and skips the connection for 60 seconds. That
may not be optimal when an error is data dependent.
FWIW, the OP's issue was with MySQL, not Postgres... The database
should be configured for client and server encoding of UTF8.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: temporary lookup error with utf8mb4 characters
Hi again,
I realized than same error is raised when database is in utf8 if email
contains utf8mb4 characters.
Which is the convenient database collation for postfix? We can force
postfix to accept only utf8 characters?.
El 13/4/23 a las 18:36, Víctor Rubiella Monfort via Postfix-users escribió:
When mysql_table lookup is executing nonascii characters and database
is in latin1, not only fails query, all sesion/connection is corrupted
and produces a lot of "temporary lookup table" errors until sesion is
recreated (about 1 minute later).
Today some external ip was trying to deliver an email with special
character on one on my legacy servers (with latin1) and produces this
errors.
I can understant that lookup fails for query with special characters,
but main issue was for all raised failures for other accounts and
lookups during 1-2 minutes. This is a knew issue?.
I deploy an workaround using "CONVERT('%s' using ascii)" until not
pass all database tables to utf8.
The main problem debuging this issue was "proxy:mysql" , "proxy" was
hiding original collation error and only shows regular lookup errors
on postfix log, when user "postmap" to debug, I only see root cause
when execute without "proxy".
postfix versions tested:
postfix 3.5.17-0+deb11u1
postfix-mysql 3.5.17-0+deb11u1
postfix 3.5.15-0+deb11u1
postfix-mysql 3.5.15-0+deb11u1
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] temporary lookup persistent after query collate error corrupt connection.
When mysql_table lookup is executing nonascii characters and database is
in latin1, not only fails query, all sesion/connection is corrupted and
produces a lot of "temporary lookup table" errors until sesion is
recreated (about 1 minute later).
Today some external ip was trying to deliver an email with special
character on one on my legacy servers (with latin1) and produces this
errors.
I can understant that lookup fails for query with special characters,
but main issue was for all raised failures for other accounts and
lookups during 1-2 minutes. This is a knew issue?.
I deploy an workaround using "CONVERT('%s' using ascii)" until not pass
all database tables to utf8.
The main problem debuging this issue was "proxy:mysql" , "proxy" was
hiding original collation error and only shows regular lookup errors on
postfix log, when user "postmap" to debug, I only see root cause when
execute without "proxy".
postfix versions tested:
postfix 3.5.17-0+deb11u1
postfix-mysql 3.5.17-0+deb11u1
postfix 3.5.15-0+deb11u1
postfix-mysql 3.5.15-0+deb11u1
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] warn_if_reject for milters equivalent?
Hi!, There are any way to implement equivalent to "warn_id_reject" for milters? I'm deploying centralized spam milter on inet:X: and I would like to deploy as "dryrun" to evaluate rejections before full enable it, and activate it gradually on different servers. Thanks! ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
