[pfx] Re: smtp code 450 and delivery to secondary MX

[Viktor Dukhovni via Postfix-users]

On Tue, Apr 18, 2023 at 10:35:22AM +0800, tom--- via Postfix-users wrote:

> So my question is, smtp code 450 will cause the sender to retry delivery 
> to secondary MX?

Yes, if the client is a legitimate MTA, less common with a junk-sending
botnet.  Once you're confident your restriction settings are sound:

plaintext_reject_code = 550
unknown_address_reject_code = 550
unknown_client_reject_code = 550
unknown_hostname_reject_code = 550
unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550

but you should rush to do this without watching your logs for some time
and fully understanding the rules you've configured.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: is localhost.localdomain a FQDN?

[Noel Jones via Postfix-users]

On 4/17/2023 9:19 PM, tom--- via Postfix-users wrote:
I saw many peer MTA connecting me with this default HELO hostname: 
localhost.localdomain.

is this a FQDN? is it valid?



Yes, it's FQDN and valid from a syntax standpoint.
That said, it's a strong spam indicator and should never be seen 
from an external connection.


I guess the spammer thinks this will trick your server into thinking 
it's local mail, or confuse someone reading logs or headers. Since 
I'm not a spammer, I don't know the actual motivation for this.


You can easily reject these with a check_helo_access map.


  -- Noel Jones

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: is localhost.localdomain a FQDN?

[Viktor Dukhovni via Postfix-users]

On Tue, Apr 18, 2023 at 10:19:58AM +0800, tom--- via Postfix-users wrote:

> I saw many peer MTA connecting me with this default HELO hostname: 
> localhost.localdomain.
>
> Is this a FQDN?

Yes, it is a fully-qualified domain name.

> Is it valid?

Depends on your perspective.  This FQDN does not exist in the global DNS
(there is no "localdomain" TLD delegated in the root zone).  This sort
of name is typical for MUAs, and not typical of well run MTAs.  Whether
this sort of name is sufficient grounds to deny access is less obvious.

If this is not a significant fraction of your unwanted mail, the filter
may not be worth the risk of blocking something misguided, but useful.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: smtp code 450 and delivery to secondary MX

[Noel Jones via Postfix-users]

On 4/17/2023 9:35 PM, tom--- via Postfix-users wrote:
When my main postfix rejected a message due to 
reject_unknown_client_hostname:


Apr 18 10:27:12 mail postfix/smtpd[129429]: NOQUEUE: reject: RCPT 
from unknown[194.33.39.17]: 450 4.7.25 Client host rejected: cannot 
find your hostname, [194.33.39.17]; from= to= 
proto=ESMTP helo=


I found this message was re-delivered by peer MTA to my secondary MX 
quickly.


So my question is, smtp code 450 will cause the sender to retry 
delivery to secondary MX?


After a 450 "defer" response, the sender is free to retry any time 
to any MX - immediately retrying a secondary MX is a reasonable action.


Also see:
http://www.postfix.org/postconf.5.html#unknown_client_reject_code
and consider changing it to 550 to permanently reject unwanted mail, 
rather than deferring it.


This is one reason that all MX servers should have the same spam 
controls and valid recipient lists. and an excuse to get rid of 
largely unnecessary secondary MX servers.


Note that reject_unknown_client_hostname is a very strict test that 
is likely to reject legit mail. Consider using 
reject_unknown_reverse_client_hostname instead.




  -- Noel Jones
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: is localhost.localdomain a FQDN?

[Phil Stracchino via Postfix-users]

On 4/17/23 22:19, tom--- via Postfix-users wrote:

I saw many peer MTA connecting me with this default HELO hostname:
localhost.localdomain.
is this a FQDN? is it valid?


No properly configured MTA should ever be advertising its identity as 
localhost.localdomain.  Assuming it is that literal string, that looks 
like AT BEST a half-configured MTA, possibly on a half-configured host.



--
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] smtp code 450 and delivery to secondary MX

[tom--- via Postfix-users]

When my main postfix rejected a message due to 
reject_unknown_client_hostname:


Apr 18 10:27:12 mail postfix/smtpd[129429]: NOQUEUE: reject: RCPT from 
unknown[194.33.39.17]: 450 4.7.25 Client host rejected: cannot find your 
hostname, [194.33.39.17]; from= to= proto=ESMTP 
helo=


I found this message was re-delivered by peer MTA to my secondary MX 
quickly.


So my question is, smtp code 450 will cause the sender to retry delivery 
to secondary MX?


Thank you
Tom
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] is localhost.localdomain a FQDN?

[tom--- via Postfix-users]

I saw many peer MTA connecting me with this default HELO hostname: 
localhost.localdomain.

is this a FQDN? is it valid?

Thanks.
Tom
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix stable release 3.8.0

[tom--- via Postfix-users]

On 2023-04-18 03:25, Wietse Venema via Postfix-users wrote:

Postfix stable release 3.8.0 is available. Postfix 3.4..3.7 will
be updated soon; after that, Postfix 3.4 will no longer be updated.

The main changes are below. See the RELEASE_NOTES file for further
details.

  * Support to look up DNS SRV records in the Postfix SMTP/LMTP
client, Based on code by Tomas Korbar (Red Hat). For example,
with "use_srv_lookup = submission" and "relayhost =
example.com:submission", the Postfix SMTP client will look up
DNS SRV records for _submission._tcp.example.com, and will relay
email through the hosts and ports that are specified with those
records.

  * TLS obsolescence: Postfix now treats the "export" and "low"
cipher grade settings as "medium". The "export" and "low" grades
are no longer supported in OpenSSL 1.1.1, the minimum version
required in Postfix 3.6.0 and later. Also, Postfix default
settings now exclude deprecated or unused ciphers (SEED, IDEA,
3DES, RC2, RC4, RC5), digest (MD5), key exchange algorithms
(DH, ECDH), and public key algorithm (DSS).

  * Attack resistance: the Postfix SMTP server can now aggregate
smtpd_client_*_rate and smtpd_client_*_count statistics by
network block instead of by IP address, to raise the bar against
a memory exhaustion attack in the anvil(8) server; Postfix TLS
support unconditionally disables TLS renegotiation in the middle
of an SMTP connection, to avoid a CPU exhaustion attack.

  * The PostgreSQL client encoding is now configurable with the
"encoding" Postfix configuration file attribute. The default
is "UTF8". Previously the encoding was hard-coded as "LATIN1",
which is not useful in the context of SMTP.

  * The postconf command now warns for #comment in or after a Postfix
parameter value. Postfix programs do not support #comment after
other text, and treat that as input.

You can find the Postfix source code at the mirrors listed at
https://www.postfix.org/.

Wietse


Thank you Wietse and all other developers.
Postfix is like battery for Tesla, fuel for spaceX, without postfix 
people can't make good and secure communications across internet.

I love postfix.

regards.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Tyler Montney via Postfix-users]

>   One important information is missing here: on what port?

Good catch. Port 25.

>   There should be no authentication on port 25 and all mail destined for
local
>   domains should be accepted.
>
>   There should be mandatory authentication on ports 465/587.
>
>   As both acme.com and corley.com are local to provider A, on port 25 any
mail
>   to any of these domains should be accepted, regardless of sender,
without
>   authentication.

And that's a definition I've been struggling with: What is *local* in
relation to SMTP?

What if I'm a managed service provider hosting email on Postfix? Are all my
customers considered local?
Wouldn't *local* be considered the domains under an organization's control?

>   However, on ports 465 or 587, authentication should be required,
regardless
>   of destination.
>
> If authentication is required on port 25, or no authentication is allowed
on
>   port 465 or 587, someone has misconfigured something.

On Mon, Apr 17, 2023 at 4:58 PM Jaroslaw Rafa via Postfix-users <
postfix-users@postfix.org> wrote:

> Dnia 17.04.2023 o godz. 14:49:11 Noel Jones via Postfix-users pisze:
> > Please keep replies on list.
> >
> > On 4/17/2023 2:16 PM, Tyler Montney wrote:
> > >I'll put it this way, since I'm struggling to word this:
> > >
> > >Provider A contains the following customers:
> > >Acme Corporation (acme.com )
> > >Corley Motors (corley.com )
> > >
> > >Provider B contains the following customers:
> > >ConSec (consec.com )
> > >Teldar Paper (teldar.com )
> > >
> > >f...@acme.com can send to b...@corley.com without authentication.
>
> One important information is missing here: on what port?
>
> There should be no authentication on port 25 and all mail destined for
> local
> domains should be accepted.
>
> There should be mandatory authentication on ports 465/587.
>
> As both acme.com and corley.com are local to provider A, on port 25 any
> mail
> to any of these domains should be accepted, regardless of sender, without
> authentication.
>
> However, on ports 465 or 587, authentication should be required, regardless
> of destination.
>
> If authentication is required on port 25, or no authentication is allowed
> on
> port 465 or 587, someone has misconfigured something.
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
> ___
> 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] Re: temporary lookup error with utf8mb4 characters

[Wietse Venema via Postfix-users]

And here is a more conservative patch for MySQL client retries.

It closes the server connection after every error, and it delays
making a new server connection only after specific errors.

Closing the connection eliminates the possibility that the client
becomes stuck.

Wietse
20230417

Cleanup: in the MySQL client, temporarily stay away from a
server only if the last error was caused by a connection-level
or protocol-level failure. File: global/dict_mysql.c.

diff -ur /var/tmp/postfix-3.9-20230416/src/global/dict_mysql.c 
./src/global/dict_mysql.c
--- /var/tmp/postfix-3.9-20230416/src/global/dict_mysql.c   2023-04-16 
16:44:39.0 -0400
+++ ./src/global/dict_mysql.c   2023-04-17 19:17:02.0 -0400
@@ -108,6 +108,7 @@
 /* Application-specific. */
 
 #include "dict_mysql.h"
+#include "mysql/errmsg.h"
 
 /* MySQL 8.x API change */
 
@@ -179,7 +180,7 @@
 static int plmysql_query(DICT_MYSQL *, const char *, VSTRING *, MYSQL_RES **);
 static void plmysql_dealloc(PLMYSQL *);
 static void plmysql_close_host(HOST *);
-static void plmysql_down_host(HOST *);
+static void plmysql_down_host(HOST *, int);
 static void plmysql_connect_single(DICT_MYSQL *, HOST *);
 static const char *dict_mysql_lookup(DICT *, const char *);
 DICT   *dict_mysql_open(const char *, int, int);
@@ -546,7 +547,16 @@
 * See what we got.
 */
if (query_error) {
-   plmysql_down_host(host);
+   switch (mysql_errno(host->db)) {
+   case CR_COMMANDS_OUT_OF_SYNC:
+   case CR_SERVER_GONE_ERROR:
+   case CR_SERVER_LOST:
+   plmysql_down_host(host, RETRY_CONN_INTV);
+   break;
+   default:
+   plmysql_down_host(host, 0);
+   break;
+   }
if (errno == 0)
errno = ENOTSUP;
if (first_result) {
@@ -609,7 +619,7 @@
 } else {
msg_warn("connect to mysql server %s: %s",
 host->hostname, mysql_error(host->db));
-   plmysql_down_host(host);
+   plmysql_down_host(host, RETRY_CONN_INTV);
 }
 }
 
@@ -625,11 +635,11 @@
  * plmysql_down_host - close a failed connection AND set a "stay away from
  * this host" timer
  */
-static void plmysql_down_host(HOST *host)
+static void plmysql_down_host(HOST *host, int delay)
 {
 mysql_close(host->db);
 host->db = 0;
-host->ts = time((time_t *) 0) + RETRY_CONN_INTV;
+host->ts = time((time_t *) 0) + delay;
 host->stat = STATFAIL;
 event_cancel_timer(dict_mysql_event, (void *) host);
 }
___
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

[Gerald Galster via Postfix-users]

>>> I've patched postfix 3.7.4 on a low volume server.
>> 
>> Thank you!
>> 
>>> "charset" has to be present and defined in all mysql configs, otherwise 
>>> startup fails:
>>> (no backwards compatibility)
>>> 
>>> postfix/proxymap[3996]: fatal: /etc/postfix/test.mysql.cf: bad string 
>>> length 0 < 1: charset =
>> 
>> Grr. In the patch, 
>> 
>>cfg_get_int(stuff, "charset", "", 1, 0) 
>> 
>> should be
>> 
>>cfg_get_int(stuff, "charset", "", 0, 0)
> 
> That should be cfg_get_str.

Thanks, I modified dict_mysql.c, recompiled and now it works as expected.

Best regards,
Gerald___
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

[Wietse Venema via Postfix-users]

Wietse Venema via Postfix-users:
> Gerald Galster via Postfix-users:
> > 
> > > Wietse Venema via Postfix-users :
> > > 
> > >>> 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.
> > >> 
> > >> Is there such an API?
> > > 
> > > Based on documentation, perhaps mysql_set_character_set() can do that. 
> > > https://dev.mysql.com/doc/c-api/8.0/en/mysql-set-character-set.html
> > > 
> > > Attached is patch 20230417-mysql-charset-patch.txt that adds a
> > > "charset" parameter to the Postfix MySQL configuration file.
> > 
> > 
> > I've patched postfix 3.7.4 on a low volume server.
> 
> Thank you!
> 
> > "charset" has to be present and defined in all mysql configs, otherwise 
> > startup fails:
> > (no backwards compatibility)
> > 
> > postfix/proxymap[3996]: fatal: /etc/postfix/test.mysql.cf: bad string 
> > length 0 < 1: charset =
> 
> Grr. In the patch, 
> 
> cfg_get_int(stuff, "charset", "", 1, 0) 
> 
> should be
> 
> cfg_get_int(stuff, "charset", "", 0, 0)

That should be cfg_get_str.

Wietse

> > Setting "charset" to the non-default cp1250 works (from mysql general_log):
> > 
> > (terminal encoding utf8)
> > # postmap -q "bl?.com" mysql:/etc/postfix/relay_domains.mysql.cf  
> > Connect postfix@localhost on postfix using Socket
> > Query SET NAMES cp1250
> > Query SELECT destination as relaydestination FROM relay WHERE domain = 
> > 'bl?.com'
> > Quit 
> > (postfix restart)
> > 
> > (terminal encoding latin1)
> > # postmap -q "bl?.com" mysql:/etc/postfix/relay_domains.mysql.cf
> > Connect postfix@localhost on postfix using Socket
> > Query SET NAMES cp1250
> > Query SELECT destination as relaydestination FROM relay WHERE domain = 
> > 'bl?.com'
> > 
> > Unfortunately I can't help with mix collation error as this mysql 8 instance
> > is configured with utf8mb4/utf8_bin, skip-character-set-client-handshake and
> > all tables are utf8mb4. I could not trigger a collation error.
> 
> No problem, I am happy that the patch does not break something that
> works without the patch.
> 
> > +# .IP "\fBcharset\fR (empty for backwards compatibility)"
> > +# The default client character set (and implicitly, the
> > +# collation order). According to MySQL documentation the
> > +# built-in default is "latin1"; for SMTP, "utf8" would be
> > +# more appropriate.
> > 
> > As of mysql 8.0 the default character set is utf8mb4:
> > https://dev.mysql.com/blog-archive/mysql-8-0-collations-migrating-from-older-collations/
> 
> I'll delete the comnment about "latin1" as it is MySQL version dependent.
> 
> > Historically utf8 had been a mysql alias for utf8mb3:
> > https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html
> 
> Again, thanks for what you could test. The error handling should
> be better because the new code will no longer skip a connection
> for 60s after every errror, but only after an error that involves a
> really messed-up connection.
> 
>   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] Re: temporary lookup error with utf8mb4 characters

[Wietse Venema via Postfix-users]

Gerald Galster via Postfix-users:
> 
> > Wietse Venema via Postfix-users :
> > 
> >>> 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.
> >> 
> >> Is there such an API?
> > 
> > Based on documentation, perhaps mysql_set_character_set() can do that. 
> > https://dev.mysql.com/doc/c-api/8.0/en/mysql-set-character-set.html
> > 
> > Attached is patch 20230417-mysql-charset-patch.txt that adds a
> > "charset" parameter to the Postfix MySQL configuration file.
> 
> 
> I've patched postfix 3.7.4 on a low volume server.

Thank you!

> "charset" has to be present and defined in all mysql configs, otherwise 
> startup fails:
> (no backwards compatibility)
> 
> postfix/proxymap[3996]: fatal: /etc/postfix/test.mysql.cf: bad string length 
> 0 < 1: charset =

Grr. In the patch, 

cfg_get_int(stuff, "charset", "", 1, 0) 

should be

cfg_get_int(stuff, "charset", "", 0, 0)

> Setting "charset" to the non-default cp1250 works (from mysql general_log):
> 
> (terminal encoding utf8)
> # postmap -q "bl?.com" mysql:/etc/postfix/relay_domains.mysql.cf  
> Connect postfix@localhost on postfix using Socket
> Query SET NAMES cp1250
> Query SELECT destination as relaydestination FROM relay WHERE domain = 
> 'bl?.com'
> Quit 
> (postfix restart)
> 
> (terminal encoding latin1)
> # postmap -q "bl?.com" mysql:/etc/postfix/relay_domains.mysql.cf
> Connect postfix@localhost on postfix using Socket
> Query SET NAMES cp1250
> Query SELECT destination as relaydestination FROM relay WHERE domain = 
> 'bl?.com'
> 
> Unfortunately I can't help with mix collation error as this mysql 8 instance
> is configured with utf8mb4/utf8_bin, skip-character-set-client-handshake and
> all tables are utf8mb4. I could not trigger a collation error.

No problem, I am happy that the patch does not break something that
works without the patch.

> +# .IP "\fBcharset\fR (empty for backwards compatibility)"
> +# The default client character set (and implicitly, the
> +# collation order). According to MySQL documentation the
> +# built-in default is "latin1"; for SMTP, "utf8" would be
> +# more appropriate.
> 
> As of mysql 8.0 the default character set is utf8mb4:
> https://dev.mysql.com/blog-archive/mysql-8-0-collations-migrating-from-older-collations/

I'll delete the comnment about "latin1" as it is MySQL version dependent.

> Historically utf8 had been a mysql alias for utf8mb3:
> https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html

Again, thanks for what you could test. The error handling should
be better because the new code will no longer skip a connection
for 60s after every errror, but only after an error that involves a
really messed-up connection.

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Jaroslaw Rafa via Postfix-users]

Dnia 17.04.2023 o godz. 14:49:11 Noel Jones via Postfix-users pisze:
> Please keep replies on list.
> 
> On 4/17/2023 2:16 PM, Tyler Montney wrote:
> >I'll put it this way, since I'm struggling to word this:
> >
> >Provider A contains the following customers:
> >Acme Corporation (acme.com )
> >Corley Motors (corley.com )
> >
> >Provider B contains the following customers:
> >ConSec (consec.com )
> >Teldar Paper (teldar.com )
> >
> >f...@acme.com can send to b...@corley.com without authentication.

One important information is missing here: on what port?

There should be no authentication on port 25 and all mail destined for local
domains should be accepted.

There should be mandatory authentication on ports 465/587.

As both acme.com and corley.com are local to provider A, on port 25 any mail
to any of these domains should be accepted, regardless of sender, without
authentication.

However, on ports 465 or 587, authentication should be required, regardless
of destination.

If authentication is required on port 25, or no authentication is allowed on
port 465 or 587, someone has misconfigured something.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Noel Jones via Postfix-users]

On 4/17/2023 3:59 PM, Tyler Montney via Postfix-users wrote:


That is the purpose of this discussion, to determine what exactly 
this scenario presents. As stated above, Provider A is aware and 
believes it's acceptable. It is acceptable because their 
documentation has features which rely on it. No justification why 
these features require it was given, so their reasoning for initial 
acceptance is poor. To put it another way, it's like RFC-Ignorant. 
You don't HAVE to list a postmaster address, but it's such a small 
gesture to play nice with the rest of the world. Why rely entirely 
on your spam filter (or unknown mitigations) when a common feature 
such as authentication will do the job? Why the risk?


This is a local spam problem.

Report abuse to your provider. If the provider is unwilling or 
unable to fix the abuse, find another provider.



  -- Noel Jones
___
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

[Gerald Galster via Postfix-users]

> Wietse Venema via Postfix-users :
> 
>>> 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.
>> 
>> Is there such an API?
> 
> Based on documentation, perhaps mysql_set_character_set() can do that. 
> https://dev.mysql.com/doc/c-api/8.0/en/mysql-set-character-set.html
> 
> Attached is patch 20230417-mysql-charset-patch.txt that adds a
> "charset" parameter to the Postfix MySQL configuration file.


I've patched postfix 3.7.4 on a low volume server.

"charset" has to be present and defined in all mysql configs, otherwise startup 
fails:
(no backwards compatibility)

postfix/proxymap[3996]: fatal: /etc/postfix/test.mysql.cf: bad string length 0 
< 1: charset =
postfix/smtpd[3995]: warning: dict_proxy_open: service proxymap: Application 
error
postfix/master[3989]: warning: process /usr/libexec/postfix/proxymap pid 3996 
exit status 1
postfix/master[3989]: warning: /usr/libexec/postfix/proxymap: bad command 
startup -- throttling

Setting "charset" to the non-default cp1250 works (from mysql general_log):

(terminal encoding utf8)
# postmap -q "blü.com" mysql:/etc/postfix/relay_domains.mysql.cf  
Connect postfix@localhost on postfix using Socket
Query SET NAMES cp1250
Query SELECT destination as relaydestination FROM relay WHERE domain = 'blü.com'
Quit 
(postfix restart)

(terminal encoding latin1)
# postmap -q "bl?.com" mysql:/etc/postfix/relay_domains.mysql.cf
Connect postfix@localhost on postfix using Socket
Query SET NAMES cp1250
Query SELECT destination as relaydestination FROM relay WHERE domain = 'blü.com'

Unfortunately I can't help with mix collation error as this mysql 8 instance
is configured with utf8mb4/utf8_bin, skip-character-set-client-handshake and
all tables are utf8mb4. I could not trigger a collation error.
 

+++ ./proto/mysql_table 2023-04-17 11:24:16.0 -0400
@@ -79,6 +79,11 @@
 # .nf
 #dbname = customer_database
 # .fi
+# .IP "\fBcharset\fR (empty for backwards compatibility)"
+# The default client character set (and implicitly, the
+# collation order). According to MySQL documentation the
+# built-in default is "latin1"; for SMTP, "utf8" would be
+# more appropriate.

As of mysql 8.0 the default character set is utf8mb4:
https://dev.mysql.com/blog-archive/mysql-8-0-collations-migrating-from-older-collations/

Historically utf8 had been a mysql alias for utf8mb3:
https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html

Best regards,
Gerald

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Tyler Montney via Postfix-users]

> Please keep replies on list.
>You've explained what's observable, but not why it's a problem.
> Any random server on the internet can send to b...@corley.com without
> authentication. The original sender may or may not authenticate to
> *their* mail server, corley.com cannot control that. So corley.com
> accepts unauthenticated mail all day long.
> How is this different?

"This provider allows unauthenticated SMTP [Provider A] ... I have tried
one of my other larger providers, Provider B, and I was unable to do this
successfully."

In context, I am able to send as anyone to anyone without restriction.
Spoofing is bad. On top of this, a similar provider preventing this implies
a problem.

But if you're attempting to deliver a message to b...@corley.com, why use
"any random server on the internet" when you can tell one of corley's
servers to do it? (This assumes Acme is a supplier of Corley and you're
trying to trick Corley into paying an invoice.) As far as I can tell, there
is no difference between a legitimate message coming from Acme or a
malicious actor spoofing Acme.

> Some providers require all to authenticate, without exception. This
> is generally considered good, but providers may use other methods to
> prevent abuse of their system.

Most messages done in this manner go to spam, so this method could be
considered an alternative. However, that is part of this discussion. Is
something like this acceptable? Why allow a substitution like this at all?
(What are the benefits of making it optional? Doesn't this go against the
nature of standardization?) How does one know when substitution is
acceptable? (In other words, can we be accused of "cherry picking"?)

> I still don't see a problem. If someone has found a way to abuse
> this, then the abuse should be reported to the provider.

That is the purpose of this discussion, to determine what exactly this
scenario presents. As stated above, Provider A is aware and believes it's
acceptable. It is acceptable because their documentation has features which
rely on it. No justification why these features require it was given, so
their reasoning for initial acceptance is poor. To put it another way, it's
like RFC-Ignorant. You don't HAVE to list a postmaster address, but it's
such a small gesture to play nice with the rest of the world. Why rely
entirely on your spam filter (or unknown mitigations) when a common feature
such as authentication will do the job? Why the risk?

On Mon, Apr 17, 2023 at 2:49 PM Noel Jones via Postfix-users <
postfix-users@postfix.org> wrote:

> Please keep replies on list.
>
> On 4/17/2023 2:16 PM, Tyler Montney wrote:
> > I'll put it this way, since I'm struggling to word this:
> >
> > Provider A contains the following customers:
> > Acme Corporation (acme.com )
> > Corley Motors (corley.com )
> >
> > Provider B contains the following customers:
> > ConSec (consec.com )
> > Teldar Paper (teldar.com )
> >
> > f...@acme.com can send to b...@corley.com
> > without authentication.
>
> You've explained what's observable, but not why it's a problem.
> Any random server on the internet can send to b...@corley.com without
> authentication. The original sender may or may not authenticate to
> *their* mail server, corley.com cannot control that. So corley.com
> accepts unauthenticated mail all day long.
> How is this different?
>
> > f...@acme.com
> > must authenticate in order to send to
> > f...@consec.com . Similarly, f...@consec.com
> > must authenticate in order to send to
> > b...@teldar.com .
> >
>
> Some providers require all to authenticate, without exception. This
> is generally considered good, but providers may use other methods to
> prevent abuse of their system.
>
> I still don't see a problem. If someone has found a way to abuse
> this, then the abuse should be reported to the provider.
>
>
>-- Noel Jones
> ___
> 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] Re: Open relay clarification

[Noel Jones via Postfix-users]

Please keep replies on list.

On 4/17/2023 2:16 PM, Tyler Montney wrote:

I'll put it this way, since I'm struggling to word this:

Provider A contains the following customers:
Acme Corporation (acme.com )
Corley Motors (corley.com )

Provider B contains the following customers:
ConSec (consec.com )
Teldar Paper (teldar.com )

f...@acme.com can send to b...@corley.com 
without authentication. 


You've explained what's observable, but not why it's a problem.
Any random server on the internet can send to b...@corley.com without 
authentication. The original sender may or may not authenticate to 
*their* mail server, corley.com cannot control that. So corley.com 
accepts unauthenticated mail all day long.

How is this different?

f...@acme.com 
must authenticate in order to send to 
f...@consec.com . Similarly, f...@consec.com 
must authenticate in order to send to 
b...@teldar.com .




Some providers require all to authenticate, without exception. This 
is generally considered good, but providers may use other methods to 
prevent abuse of their system.


I still don't see a problem. If someone has found a way to abuse 
this, then the abuse should be reported to the provider.



  -- Noel Jones
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Postfix stable release 3.8.0

[Wietse Venema via Postfix-users]

Postfix stable release 3.8.0 is available. Postfix 3.4..3.7 will
be updated soon; after that, Postfix 3.4 will no longer be updated.

The main changes are below. See the RELEASE_NOTES file for further
details.

  * Support to look up DNS SRV records in the Postfix SMTP/LMTP
client, Based on code by Tomas Korbar (Red Hat). For example,
with "use_srv_lookup = submission" and "relayhost =
example.com:submission", the Postfix SMTP client will look up
DNS SRV records for _submission._tcp.example.com, and will relay
email through the hosts and ports that are specified with those
records.

  * TLS obsolescence: Postfix now treats the "export" and "low"
cipher grade settings as "medium". The "export" and "low" grades
are no longer supported in OpenSSL 1.1.1, the minimum version
required in Postfix 3.6.0 and later. Also, Postfix default
settings now exclude deprecated or unused ciphers (SEED, IDEA,
3DES, RC2, RC4, RC5), digest (MD5), key exchange algorithms
(DH, ECDH), and public key algorithm (DSS).

  * Attack resistance: the Postfix SMTP server can now aggregate
smtpd_client_*_rate and smtpd_client_*_count statistics by
network block instead of by IP address, to raise the bar against
a memory exhaustion attack in the anvil(8) server; Postfix TLS
support unconditionally disables TLS renegotiation in the middle
of an SMTP connection, to avoid a CPU exhaustion attack.

  * The PostgreSQL client encoding is now configurable with the
"encoding" Postfix configuration file attribute. The default
is "UTF8". Previously the encoding was hard-coded as "LATIN1",
which is not useful in the context of SMTP.

  * The postconf command now warns for #comment in or after a Postfix
parameter value. Postfix programs do not support #comment after
other text, and treat that as input.

You can find the Postfix source code at the mirrors listed at
https://www.postfix.org/.

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Open relay clarification

[Noel Jones via Postfix-users]

On 4/17/2023 1:38 PM, Tyler Montney via Postfix-users wrote:


I use a mail provider (Provider A) which has thousands of 
organizations. This provider allows unauthenticated SMTP to other 
organizations so long as they're using them as a provider (within 
their ecosystem). Of course, you cannot send unauthenticated email 
to other providers. I have tried one of my other larger providers, 
Provider B, and I was unable to do this successfully. Provider A 
claims this behavior is by design, as some devices have simple or no 
authentication capabilities. Provider B has similar allowances but 
all of their methods require a form of authentication.


I'm probably missing something... If they're willing to accept 
(unauthenticated) general internet mail from any well-behaved server 
to their customer, what does it matter if it's from another customer?


Sure, most providers require authentication to send any mail, but I 
don't see where this is a problem.


  -- Noel Jones
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Open relay clarification

[Tyler Montney via Postfix-users]

Before getting started, this has been publicly disclosed by someone else a
while ago. However, I still don't think it's necessary to name the
organization to explain myself. My goal here is not only to give a proper
argument to the provider, but also my own curiosity and research (on the
workings of SMTP).

I use a mail provider (Provider A) which has thousands of organizations.
This provider allows unauthenticated SMTP to other organizations so long as
they're using them as a provider (within their ecosystem). Of course, you
cannot send unauthenticated email to other providers. I have tried one of
my other larger providers, Provider B, and I was unable to do this
successfully. Provider A claims this behavior is by design, as some devices
have simple or no authentication capabilities. Provider B has similar
allowances but all of their methods require a form of authentication.

Mechanisms such as SPF or spam filtering certainly are effective here, but
unauthenticated SMTP seems like a core failing. "Open relay" is the first
thing that comes to mind; however, is it really an open relay? As
mentioned, I cannot send from Provider A to Provider B. The scope is
limited to just this ecosystem. But is there an expectation on how limited
that really is? Say for instance only Provider A and Provider B existed in
all the world, and Provider B was 1% of all servers. Surely that would not
be acceptable to most.

It is my belief that unauthenticated SMTP best practice should only
function when sending within the same domain (f...@domain.com -->
b...@domain.com). Unless they're in an approved senders list, it does not
matter whether the same server, company, ecosystem, and so forth. (Perhaps
there is some unforeseen dependency in being a multi-organization mail
provider, where this is required.) I have reviewed RFC 2821 but have not
found anything concrete, just that it MAY accept or reject as it sees fit
[3.7].
___
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

[Wietse Venema via Postfix-users]

Wietse Venema via Postfix-users:
> > 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.
> 
> Is there such an API?

Based on documentation, perhaps mysql_set_character_set() can do that. 
https://dev.mysql.com/doc/c-api/8.0/en/mysql-set-character-set.html

Attached is patch 20230417-mysql-charset-patch.txt that adds a
"charset" parameter to the Postfix MySQL configuration file.  

I don't have a MySQL testbed; someone else would have to test this,
or this would have to wait until I have time to set up MySQL.

> > - mix collation error should raise 1 error, but next queries should be 
> > work ok, this could be considered and issue right?.
> 
> For the Postfix MySQL client the expected result of a query is:
> 
> - found,
> 
> - not found,
> 
> - error.
> 
> The client does not distinguish between errors, and all errors have
> the same result (skip this connection for 60s). That code is almost
> 20 years old, so I wonder if you are doing something unusal that
> other people aren't doing.
> 
> Based on https://dev.mysql.com/doc/c-api/8.0/en/mysql-next-result.html
> I suppose that the client could distinguish between
> errors that indicate a connection error and other errors. But that
> would be a major code change.

It is possible to distinguish between errors without having tp
restructure code.

Attached is patch 20230417-mysql-retry-patch.txt that more selectively
backs off from a server connection. 

Again if someone else can test this, great, otherwise this will
have to wait.

Wietse
20230417

Cleanup: in the MySQL client, temporarily stay away from a
server only if the last error was caused by connection-level
failure. File: global/dict_mysql.c.

diff '--exclude=man' '--exclude=html' '--exclude=README_FILES' 
'--exclude=INSTALL' '--exclude=.indent.pro' -r -ur 
/var/tmp/postfix-3.9-20230416/src/global/dict_mysql.c ./src/global/dict_mysql.c
--- /var/tmp/postfix-3.9-20230416/src/global/dict_mysql.c   2023-04-16 
16:44:39.0 -0400
+++ ./src/global/dict_mysql.c   2023-04-17 11:07:47.0 -0400
@@ -108,6 +108,7 @@
 /* Application-specific. */
 
 #include "dict_mysql.h"
+#include "mysql/errmsg.h"
 
 /* MySQL 8.x API change */
 
@@ -546,7 +547,14 @@
 * See what we got.
 */
if (query_error) {
-   plmysql_down_host(host);
+   switch (mysql_errno(host->db)) {
+   case CR_COMMANDS_OUT_OF_SYNC:
+   case CR_SERVER_GONE_ERROR:
+   case CR_SERVER_LOST:
+   plmysql_down_host(host);
+   default:
+   break;
+   }
if (errno == 0)
errno = ENOTSUP;
if (first_result) {
diff '--exclude=man' '--exclude=html' '--exclude=README_FILES' 
'--exclude=INSTALL' '--exclude=.indent.pro' -r -ur 
/var/tmp/postfix-3.9-20230416/HISTORY ./HISTORY
--- /var/tmp/postfix-3.9-20230416/HISTORY   2023-04-16 17:09:29.0 
-0400
+++ ./HISTORY   2023-04-17 11:01:00.531589777 -0400
@@ -27055,3 +27055,9 @@
Cleanup: in source-code comments, replaced redundant (and
sometimes incomplete) lookup table configuration info with
a reference to the corresponding *_table(5) manpage.
+
+20230417
+
+   Cleanup: in the MySQL client, make the default characterset
+   (and collation) configurable (the MySQL defaults are latin1
+   and latin1_swedish_ci). File: global/dict_mysql.c.
diff '--exclude=man' '--exclude=html' '--exclude=README_FILES' 
'--exclude=INSTALL' '--exclude=.indent.pro' -r -ur 
/var/tmp/postfix-3.9-20230416/proto/mysql_table ./proto/mysql_table
--- /var/tmp/postfix-3.9-20230416/proto/mysql_table 2022-12-27 
18:01:00.0 -0500
+++ ./proto/mysql_table 2023-04-17 11:24:16.0 -0400
@@ -79,6 +79,11 @@
 # .nf
 #  dbname = customer_database
 # .fi
+# .IP "\fBcharset\fR (empty for backwards compatibility)"
+#  The default client character set (and implicitly, the
+#  collation order). According to MySQL documentation the
+#  built-in default is "latin1"; for SMTP, "utf8" would be
+#  more appropriate.
 # .IP "\fBquery\fR"
 #  The SQL query template used to search the database, where \fB%s\fR
 #  is a substitute for the address Postfix is trying to resolve,
diff '--exclude=man' '--exclude=html' '--exclude=README_FILES' 
'--exclude=INSTALL' '--exclude=.indent.pro' -r -ur 
/var/tmp/postfix-3.9-20230416/src/global/dict_mysql.c ./src/global/dict_mysql.c
--- /var/tmp/postfix-3.9-20230416/src/global/dict_mysql.c   2023-04-16 
16:44:39.0 -0400
+++ ./src/global/dict_mysql.

[pfx] Re: Postfix refuses to accept email from video camera

[Jan Ceuleers via Postfix-users]

On 16/04/2023 21:11, Viktor Dukhovni via Postfix-users wrote:
> Not surprising,

I suspect that the OP did not recognise the $ and # characters in your
instructions as shell prompts (to be omitted from the commands being
executed), and copy/pasted them into his shell as-is.

HTH, Jan
___
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

[Wietse Venema via Postfix-users]

V?ctor Rubiella Monfort via Postfix-users:
> 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.

Is there such an API?

> - mix collation error should raise 1 error, but next queries should be 
> work ok, this could be considered and issue right?.

For the Postfix MySQL client the expected result of a query is:

- found,

- not found,

- error.

The client does not distinguish between errors, and all errors have
the same result (skip this connection for 60s). That code is almost
20 years old, so I wonder if you are doing something unusal that
other people aren't doing.

Based on https://dev.mysql.com/doc/c-api/8.0/en/mysql-next-result.html
I suppose that the client could distinguish between
errors that indicate a connection error and other errors. But that
would be a major code change.

It would help if you could show the warning that Postfix logs.

mysql:/file/name: query failed (mysql_next_result): >>>THIS TEXT

> - with "smtputf8_enable = no" I should be able to work without this kind 
> of issues right?

No. With "smtputf8_enable = no", Postfix will not verify that a
query contains malformed text. This can result in errors from the
MySQL server.

On the other hand, with "smtputf8_enable = yes", Postfix will skip
a query that contains malformed UTF-8, thus avoiding errors from
the MySQL server.

> For modern protocols I can undestant change to utf8, but utf8mb4? this 
> is much more expensive for the database, is it really necessary?

By design UTF-8 is a multi-byte encoding for all non-ASCII characters.
The only single-byte in UTF-8 is the ASCII subset.

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: header_checks not work with regexp

[Matus UHLAR - fantomas via Postfix-users]

On 17.04.23 08:54, SysAdmin EM via Postfix-users wrote:

Hello everyone the problem persists. Maybe I’m doing something wrong.

Step 1, I add the rule in the /etc/postfix/header_checks file

/^Subject:.*You may need to add/ DISCARD TMP_BLOCK

Step 2, postmap /etc/postfix/header_checks and postfix surcharge.
Are these steps correct?


you don't need to use postmap for regexp maps.


Could the problem occur because the postfix-regexp library is not installed?


which OS/distribution do you use?

does running "postconf -m" show regexp as one of map types?

--
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.
Microsoft dick is soft to do no harm
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: header_checks not work with regexp

[SysAdmin EM via Postfix-users]

Hello everyone the problem persists. Maybe I’m doing something wrong.

Step 1, I add the rule in the /etc/postfix/header_checks file

/^Subject:.*You may need to add/ DISCARD TMP_BLOCK

Step 2, postmap /etc/postfix/header_checks and postfix surcharge.

Are these steps correct?

Could the problem occur because the postfix-regexp library is not installed?
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: any web.de staff here?

[Jaroslaw Rafa via Postfix-users]

Dnia 17.04.2023 o godz. 01:44:34 Gerald Galster via Postfix-users pisze:
> 
> Common practice in Germany is: once your server accepts an email it is
> responsible for delivery. You cannot silently discard it.

But you can still reject a submission and not accept it in the first place.
Why aren't they doing it?

> I'm not affiliated with web.de but the only reason I can see is that
> they want to uphold a good reputation while still offering popular
> forwarding. Even a 99% spam filter rate would be problematic at scale.

But if they put all forwarded emails via the "spam" outgoing server, it
effectively makes the forwarding non-functional.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org