[pfx] Re: `postfix-pgsql`: Issues with expansion parameters `%s`, `%u` and `%d`, and some minor bugs(?)
On Fri, Oct 25, 2024 at 01:42:40PM +1100, Viktor Dukhovni via Postfix-users wrote: > So we only support "postgresql:" and [not] "postgres:", because with non-URL > hosts, we use a legacy API to separately specify host, port, database, > username and password: > > > https://github.com/vdukhovni/postfix/blob/a5b1b93841f14c32ddc9772887a664e7736b3826/postfix/src/global/dict_pgsql.c#L567-L573 Added a missing [not]. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] Re: list message posting loop
Wietse Venema via Postfix-users: > Viktor Dukhovni via Postfix-users: > > On Thu, Oct 24, 2024 at 09:28:30AM -0400, Wietse Venema via Postfix-users > > wrote: > > > > > Can that (also) be fixed? If mail is delivered with LMTP, please add > > > > > > -o flags=D > > > > > to the LMTP command line. > > > IIRC Wietse "misspoke" here, the "flags=..." argument is not a main.cf > > parameter override, so this is a positional argument, not an "option" Ack. It's not an option. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: `postfix-pgsql`: Issues with expansion parameters `%s`, `%u` and `%d`, and some minor bugs(?)
Viktor Dukhovni via Postfix-users: > On Thu, Oct 24, 2024 at 12:00:42PM -0400, Wietse Venema via Postfix-users > wrote: > > I have updated the hosts example, and added that the dbname field > > is required but ignored when the hosts field specifies only URI > > forms. > > > > Examples: > > hosts = > > postgresql://usern...@example.com/databasename?sslmode=require > > ... > >dbname (required) > > The database name on the servers. Example: > > dbname = customer_database > > > > This setting is required, but ignored when a postgresql:// URI > > specifies a database name. > > > > We could add a ton of code to parse a postgresql:// URI and find > > out if it specifies a database name, but that does not seem right. > > Note, my cursory look at the code suggests that URI connection strings > MUST specify a database name, the required "dbname" parameter is never > used to augment the URI, even if it appears to not include the required > databasename path component. I was thinking of URIs that specify no database name. postgresql://localhost postgresql://localhost:5432 postgresql://user@localhost postgresql://user:secret@localhost Does that mean it will use a hard-coded database name? Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: `postfix-pgsql`: Issues with expansion parameters `%s`, `%u` and `%d`, and some minor bugs(?)
On Thu, Oct 24, 2024 at 07:35:26PM -0400, Wietse Venema via Postfix-users wrote:
> > Note, my cursory look at the code suggests that URI connection strings
> > MUST specify a database name, the required "dbname" parameter is never
> > used to augment the URI, even if it appears to not include the required
> > databasename path component.
>
> I was thinking of URIs that specify no database name.
>
> postgresql://localhost
> postgresql://localhost:5432
> postgresql://user@localhost
> postgresql://user:secret@localhost
>
> Does that mean it will use a hard-coded database name?
At least for unix-domain socket connections, Postgres appears to
default a database equal to the username attempting the connection.
With "hosts = postgresql:///" I get:
postmap: warning: connect to pgsql server postgresql:///: connection to
server on socket "/run/postgresql/.s.PGSQL.5432" failed: FATAL: database
"viktor" does not exist?
postmap: fatal: table pgsql:/tmp/table.cf: query error: Application error
while with "hosts = postgresql:///dane", I am able to make queries
against the DANE/DNSSEC survey database:
$ postmap -q postfix.org pgsql:/tmp/table.cf
list.sys4.de
Lots of text at: https://www.postgresql.org/docs/16/libpq-connect.html
It also mentions that:
The URI scheme designator can be either postgresql:// or
postgres://.
Perhaps we should support both?
All the while the unused "dbname" was set to "dane".
https://github.com/vdukhovni/postfix/blob/a5b1b93841f14c32ddc9772887a664e7736b3826/postfix/src/global/dict_pgsql.c#L565-L573
static void plpgsql_connect_single(DICT_PGSQL *dict_pgsql, HOST *host)
{
if (host->type == TYPECONNSTR) {
host->db = PQconnectdb(host->name);
} else {
host->db = PQsetdbLogin(host->name, host->port, NULL, NULL,
dict_pgsql->dbname, dict_pgsql->username,
dict_pgsql->password);
}
...
The "dict_pgsql->dbname" value is only used for non-URI "hosts" elements.
I've never used "pgsql" tables myself. The only Postgres database I
operate listens only on a unix-domain socket. I don't
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: `postfix-pgsql`: Issues with expansion parameters `%s`, `%u` and `%d`, and some minor bugs(?)
On Thu, Oct 24, 2024 at 10:24:29PM -0400, Wietse Venema via Postfix-users wrote: > I suppose that the PostgreSQL client library code is looking up the > username, and using that as the default database name for a connection > URI. Yes, something like that. > Viktor, I don't think that Postfix's pgsql client cares what URI > scheme is being used, as long as the PostgreSQL client library finds > it acceptable. So we can simplify the text to: Sadly, I believe the Postfix pgsql driver reaches in and does some minimal parsing of each host to determine whether it is a URI or not: https://github.com/vdukhovni/postfix/blob/a5b1b93841f14c32ddc9772887a664e7736b3826/postfix/src/global/dict_pgsql.c#L763-L785 > PGSQL PARAMETERS >hosts The hosts that Postfix will try to connect to and > query from. Besides a PostgreSQL connection URI, > this setting supports the historical forms unix:/pathname > for UNIX-domain sockets and [...] So we only support "postgresql:" and "postgres:", because with non-URL hosts, we use a legacy API to separately specify host, port, database, username and password: https://github.com/vdukhovni/postfix/blob/a5b1b93841f14c32ddc9772887a664e7736b3826/postfix/src/global/dict_pgsql.c#L567-L573 -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: list message posting loop (was: ... smtp_tls_security_level ...)
> Perhaps a Mailman "tuneup" is possible to harden it against this sort > of loop. Victor an I had a look and made some changes. I hope this mail goes through :) -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration Invalidenstraße 120/121 | D-10115 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | https://www.charite.de ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: smtp_tls_security_level defaults question
Viktor Dukhovni via Postfix-users:
> Meanwhile, on the server side we could set:
>
> # Default to "may" when a cert file is configured.
> #
> smtpd_tls_security_level =
> ${smtpd_tls_chain_files ? {may} :
> {${smtpd_tls_cert_file ? {may} :
> {${smtpd_tls_eccert_file ? {may} :
> {${smtpd_tls_dcert_file ? {may
>
> Possibly with a top-level compatibility-level guard.
The compatibility-level guard is a good idea. To take out some of
the guesswork, I'm considering to add a read-only configuration
parameter that indicates whether Postfix is built with TLS support.
For the Postfix SMTP client the new default would look like:
smtp_tls_security_level =
${{$compatibility_level} >=level {3.10}?
{${built_with_tls ? {may
And for the Postfix SMTP server, this would add two guards
to Viktor's example:
smtpd_tls_security_level =
${{$compatibility_level} >=level {3.10} ?
{${built_with_tls ?
{${smtpd_tls_chain_files ? {may} :
{${smtpd_tls_cert_file ? {may} :
{${smtpd_tls_eccert_file ? {may} :
{${smtpd_tls_dcert_file ? {may
Configuration like this is ugly, and is acceptable only for
compiled-in default settings.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] General feedback on my postfix setup?
Hello Postfix fellows, Could you please give me your feedback on my postfix (with dovecot LMTP and virtual users in MySQL db) setup? Here's my main.cf and master.cf contents; https://www.pastebin.cz/en/p/fqcoW8Q Anything unneeded, excessive, exaggerated, abusive or wrong there, please? Many thanks in advance, Regards Mark ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] Re: list message posting loop
Viktor Dukhovni via Postfix-users: > On Thu, Oct 24, 2024 at 09:28:30AM -0400, Wietse Venema via Postfix-users > wrote: > > > Can that (also) be fixed? If mail is delivered with LMTP, please add > > > > -o flags=D > > > to the LMTP command line. You missed that last part. Command lines are conifgured in master.cf.. Wietse > IIRC Wietse "misspoke" here, the "flags=..." argument is not a main.cf > parameter override, so this is a positional argument, not an "option" > > lmtp unix ... smtp > -o ... > -o ... > ... > # no -o here > flags=DX > > -- > Viktor. > ___ > 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: [ext] Re: list message posting loop
* Wesley via Postfix-users : > > > Perhaps a Mailman "tuneup" is possible to harden it against this sort > > > of loop. > > > > Victor an I had a look and made some changes. I hope this mail goes > > through :) > > Why they had a chinese string added in the subject? Because some chinese server resent the mail back here (thus creating a loop). -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration Invalidenstraße 120/121 | D-10115 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | https://www.charite.de ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] Re: list message posting loop
On Thu, Oct 24, 2024 at 09:28:30AM -0400, Wietse Venema via Postfix-users wrote: > Can that (also) be fixed? If mail is delivered with LMTP, please add > > -o flags=D IIRC Wietse "misspoke" here, the "flags=..." argument is not a main.cf parameter override, so this is a positional argument, not an "option" lmtp unix ... smtp -o ... -o ... ... # no -o here flags=DX -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: `postfix-pgsql`: Issues with expansion parameters `%s`, `%u` and `%d`, and some minor bugs(?)
I have updated the hosts example, and added that the dbname field is required but ignored when the hosts field specifies only URI forms. Examples: hosts = postgresql://usern...@example.com/databasename?sslmode=require ... dbname (required) The database name on the servers. Example: dbname = customer_database This setting is required, but ignored when a postgresql:// URI specifies a database name. We could add a ton of code to parse a postgresql:// URI and find out if it specifies a database name, but that does not seem right. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: list message posting loop
On Thu, Oct 24, 2024 at 08:32:22PM +0800, Wesley via Postfix-users wrote: > On 2024-10-24 20:13, Ralf Hildebrandt via Postfix-users wrote: > > Why they had a chinese string added in the subject? A typical corporate "security" feature, the Chinese text reads "External Mail". Sadly the same system then sends the message to the header rather than the envelope recipient. And even sets the envelope sender to the header "From:" address. You'd expect this sort of thing in an MUA, but it has no place in server-side email handling software. So this is another instance of what is sometimes called "crapware". - Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: General feedback on my postfix setup?
On Thu, 24 Oct 2024 at 13:02, Mark via Postfix-users < postfix-users@postfix.org> wrote: > Hello Postfix fellows, > > Could you please give me your feedback on my postfix (with dovecot > LMTP and virtual users in MySQL db) setup? > > Here's my main.cf and master.cf contents; > > https://www.pastebin.cz/en/p/fqcoW8Q > > Anything unneeded, excessive, exaggerated, abusive or wrong there, please? > I'm always a bit unclear about the utility of specifying things in helo/sender_restrictions. I tend to put it all in recipient_restrictions and be done with it. BTW I take it you're not using postscreen as you have rspamd, is that correct? Jonathan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: smtp_tls_security_level defaults question
On Thu, Oct 24, 2024 at 11:33:22 -0400, Wietse Venema via Postfix-users wrote:
> And for the Postfix SMTP server, this would add two guards
> to Viktor's example:
>
> smtpd_tls_security_level =
> ${{$compatibility_level} >=level {3.10} ?
> {${built_with_tls ?
> {${smtpd_tls_chain_files ? {may} :
> {${smtpd_tls_cert_file ? {may} :
> {${smtpd_tls_eccert_file ? {may} :
> {${smtpd_tls_dcert_file ? {may
>
> Configuration like this is ugly, and is acceptable only for
> compiled-in default settings.
I would think that a postfix installer or packager that installs a default
certificate, can also add an explicit "smtpd_tls_security_level = may" to
the accompanying main.cf, so all these conditions are not really necessary
for the server side?
For the client side, with no dependencies beyond "built_with_tls", it's a
good idea.
Geert
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: smtp_tls_security_level defaults question
On Thu, Oct 24, 2024 at 01:24:07PM +0300, Eugene R via Postfix-users wrote:
> On 24.10.2024 08:24, Viktor Dukhovni via Postfix-users wrote:
> > Yes, of course, as documented. TLS is off by default, this is
> > backwards-compatible behaviour, and Postfix aims to not "surprise"
> > operators with unexpected new behaviour after an upgrade. Default
> > settings are in part also the responsibility of vendor distributions
> > that determine how the Postfix software is built, and what settings
> > are used in initial deployments.
> >
> > Now perhaps at this point, we could (if Wietse concurs) change the
> > default security level to "may" when (almost always nowdays) TLS is
> > enabled at compile time. Gmail stats for TLS in/out are quite close
> > lately to 100% in both directions:
>
> But with "TLS on by default out of the box", who and how will be responsible
> for providing the valid certificates? I am not sure it can (and should) be
> handled automatically, as it requires an operator to make certain policy and
> technical decisions as well as to specify various data values. Even when
> using, e.g., a script from Dovecot to generate a self-signed certificate.
We're talking about the SMTP client, not the server. As for the server,
OS distros could easily arrange to generate a "snake-oil" (self-signed)
cert (IIRC Debian has one by default).
Meanwhile, on the server side we could set:
# Default to "may" when a cert file is configured.
#
smtpd_tls_security_level =
${smtpd_tls_chain_files ? {may} :
{${smtpd_tls_cert_file ? {may} :
{${smtpd_tls_eccert_file ? {may} :
{${smtpd_tls_dcert_file ? {may
Possibly with a top-level compatibility-level guard.
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: smtp_tls_security_level defaults question
Geert Hendrickx:
> On Thu, Oct 24, 2024 at 11:33:22 -0400, Wietse Venema via Postfix-users wrote:
> > And for the Postfix SMTP server, this would add two guards
> > to Viktor's example:
> >
> > smtpd_tls_security_level =
> > ${{$compatibility_level} >=level {3.10} ?
> > {${built_with_tls ?
> > {${smtpd_tls_chain_files ? {may} :
> > {${smtpd_tls_cert_file ? {may} :
> > {${smtpd_tls_eccert_file ? {may} :
> > {${smtpd_tls_dcert_file ? {may
> >
> > Configuration like this is ugly, and is acceptable only for
> > compiled-in default settings.
>
>
> I would think that a postfix installer or packager that installs a default
> certificate, can also add an explicit "smtpd_tls_security_level = may" to
> the accompanying main.cf, so all these conditions are not really necessary
> for the server side?
Agreed, this would not work "out of the box" because of the external
dependency.
This may be done instead with the command "postfix tls enable-server",
which generates a certificate and which sets smtpd_tls_security_level.
> For the client side, with no dependencies beyond "built_with_tls", it's a
> good idea.
Agreed, this would work out of the box.
This would make the command "postfix tls enable-client" mostly obsolete.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] Re: list message posting loop
Ralf Hildebrandt via Postfix-users: > * Wesley via Postfix-users : > > > > > Perhaps a Mailman "tuneup" is possible to harden it against this sort > > > > of loop. > > > > > > Victor an I had a look and made some changes. I hope this mail goes > > > through :) > > > > Why they had a chinese string added in the subject? > > Because some chinese server resent the mail back here (thus creating a > loop). And for some reason mail from list.sys4.de has adds no DELIVERED-TO: header that would have (also) stopped this loop. Can that (also) be fixed? If mail is delivered with LMTP, please add -o flags=D to the LMTP client command line. If it is delivered with PIPE, then the same setting applies there. Wietse SMTP,(LMTP)SMTP,(LMTP) NAME smtp, lmtp - Postfix SMTP+LMTP client ... flags=DORX (optional) Optional message processing flags. D Prepend a "Delivered-To: recipient" message header with the envelope recipient address. Note: for this to work, the transport_destination_recipient_limit must be 1 (see SINGLE-RECIPIENT DELIVERY above for details). The D flag also enforces loop detection: if a message al? ready contains a Delivered-To: header with the same re? cipient address, then the message is returned as undeliv? erable. The address comparison is case insensitive. This feature is available as of Postfix 3.5. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: change only domain when Email send via postfix
On Wed, Oct 23, 2024 at 06:53:32PM +0200, postfixmailing--- via Postfix-users
wrote:
> I would like change Domain name of all outgoing Email:
>
> user@domainA -> user@domainB
main.cf:
smtp_generic_maps = inline:{ {@domainA = @domainB} }
If you are relaying some SMTP email inbound as well as outbound,
and to exclude inbound traffic, then apply this setting in master.cf
master.cf:
smtp unix ... smtp
-o { smtp_generic_maps = inline:{ {@domainA = @domainB} } }
...
relay unix ... smtp
...
Use the "relay" transport for inbound SMTP deliveries, and "smtp" for
outbound deliveries. This actually default behaviour if the inbound
destinations are listed in "relay_domains". But if you explicit
transport table entries, you need to be diligent about using the
right transport:
transport:
inside.example relay:inside-gw.example
outside.example smtp:outside-gw.example
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: `postfix-pgsql`: Issues with expansion parameters `%s`, `%u` and `%d`, and some minor bugs(?)
On Fri, Oct 25, 2024 at 11:46:38AM +1100, Viktor Dukhovni via Postfix-users wrote: > On Thu, Oct 24, 2024 at 07:35:26PM -0400, Wietse Venema via Postfix-users > wrote: > > > > Note, my cursory look at the code suggests that URI connection strings > > > MUST specify a database name, the required "dbname" parameter is never > > > used to augment the URI, even if it appears to not include the required > > > databasename path component. > At least for unix-domain socket connections, Postgres appears to > default a database equal to the username attempting the connection. The same is true over tcp. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: `postfix-pgsql`: Issues with expansion parameters `%s`, `%u` and `%d`, and some minor bugs(?)
On Thu, Oct 24, 2024 at 12:00:42PM -0400, Wietse Venema via Postfix-users wrote: > I have updated the hosts example, and added that the dbname field > is required but ignored when the hosts field specifies only URI > forms. > > Examples: > hosts = > postgresql://usern...@example.com/databasename?sslmode=require > ... >dbname (required) > The database name on the servers. Example: > dbname = customer_database > > This setting is required, but ignored when a postgresql:// URI > specifies a database name. > > We could add a ton of code to parse a postgresql:// URI and find > out if it specifies a database name, but that does not seem right. Note, my cursory look at the code suggests that URI connection strings MUST specify a database name, the required "dbname" parameter is never used to augment the URI, even if it appears to not include the required databasename path component. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] Re: list message posting loop
On 25/10/2024 00:35, Ralf Hildebrandt via Postfix-users wrote: * Wietse Venema via Postfix-users : And for some reason mail from list.sys4.de has adds no DELIVERED-TO: header that would have (also) stopped this loop. That has also been added while we were at it. Can that (also) be fixed? If mail is delivered with LMTP, please add -o flags=D to the LMTP client command line. Yep, that should be active now. I've just noticed you've asked about this on the Mailman 2 mailing list, you should ask on the mm3 list, which is at mailman3.org. Cheers, GaryB-) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: OpenSSL compile vs. runtime version warning
On Thu, Oct 24, 2024 at 20:00:05 +1100, Viktor Dukhovni via Postfix-users wrote: > And this is the logic used in Postfix >= 3.10-20240612, but while you've > upgraded to a shiny new OpenSSL, you haven't also upgraded to a shiny new > Postfix snapshot. :-) This is using standard Arch Linux packages for OpenSSL 3.4.0 and Postfix 3.9.0. But thanks for confirming it will be fixed in Postfix 3.10. For now I'll just ask Arch maintainers to rebuild the postfix package with the new openssl lib. Geert ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: `postfix-pgsql`: Issues with expansion parameters `%s`, `%u` and `%d`, and some minor bugs(?)
On Thu, Oct 24, 2024 at 11:31:13AM +0200, Thomas Landauer via Postfix-users wrote: > I think I found some bugs in `postfix-pgsql` lookup, or at least the > docs don't match the actual behavior. > > 1: > The expansion parameters `%s`, `%u` and `%d` are not working as documented: You're mistaken. The behaviour is exactly as documented. > If I'm just using `%s` in my query template like this: > > > query = SELECT foo FROM mytable WHERE foo = '%s' > > ... then I'm getting *three* queries in my PostgreSQL log: > > > 2024-10-21 12:38:37.556 UTC [32997] postfix@db LOG: statement: SELECT foo > > FROM mytable WHERE foo = 'u...@example.com' > > 2024-10-21 12:38:37.559 UTC [32997] postfix@db LOG: statement: SELECT foo > > FROM mytable WHERE foo = 'user' > > 2024-10-21 12:38:37.561 UTC [32997] postfix@db LOG: statement: SELECT foo > > FROM mytable WHERE foo = '@example.com' These are three separate queries with the full address, the user part and the domain part, as documented for various address rewriting tables. See virtual(5), aliases(5), canonical(5), ... > So it looks like if `%s` doesn't yield a result, then another try with `%u`, > and a third with `%d` is made. Nothing of the sort, rather higher-level facilities issue multiple queries with separate lookup keys. > But when using `%d` in the query template, the behavior differs in two > aspects: > Firstly, the same query is executed *twice*: The bare user query is suppressed, as documented, it lacks a domain. > > 2024-10-21 13:00:13.914 UTC [33773] postfix@db LOG: statement: SELECT foo > > FROM mytable WHERE foo = 'example.com' > > 2024-10-21 13:00:13.916 UTC [33773] postfix@db LOG: statement: SELECT foo > > FROM mytable WHERE foo = 'example.com' > > And secondly, note the different expansions for `%d`: > `@example.com` in the above queries, vs. > `example.com` here. Well, you asked for '%d' so that's what you got. > 2: > This line at https://www.postfix.org/pgsql_table.5.html is wrong: > > > hosts = postgresql://usern...@example.com/tablename?sslmode=require > > I guess it should be: > > hosts = postgresql://username:password@127.0.0.1/databasename > > `sslmode` isn't documented at all. The "sslmode" parameter is documented: https://www.postgresql.org/docs/9.2/app-psql.html What problem were you having with that connection string? If you're trying to say that "tablename" should be "databasename", then you're right. > 3: > The encoding doesn't work as documented: > > > The encoding used by the database client. The default setting is: > > encoding = UTF8 > > However, the default setting seems to be LATIN1 in fact, cause I'm getting > this in my PostgreSQL log: > > > 2024-10-21 12:15:07.424 UTC [31953] postfix@db LOG: statement: set > > client_encoding to 'LATIN1' > > 2024-10-21 12:15:07.428 UTC [31953] postfix@db LOG: statement: SELECT ... What version of Postfix are you using? The switch from "LATIN1" to "UTF8" is recent. postfix-3.8-20220509 diff --git a/postfix/HISTORY b/postfix/HISTORY index 3da460d7d..14ed05def 100644 --- a/postfix/HISTORY +++ b/postfix/HISTORY @@ -26495,3 +26495,10 @@ Apologies for any names omitted. Documentation: added POSTLOG_SERVICE and POSTLOG_HOSTNAME to the import_environment description. File: proto/postconf.proto. + +20220509 + + Cleanup: the pgsql: client encoding is now configurable + with the "encoding" configuration file attribute. The default + is "UTF8". Previously the encoding was hard-coded as "LATIN1". + Files: global/dict_pgsql,c, proto/pgsql_table. For documentation about your version of Postfix, look at the manpage for pgsql-table(5) that shipped with your system. > Furthermore, changing the encoding doesn't work - this seems to be a bug in > the code (not just in the docs): > > When trying to append it to the connection string like that: > > > hosts = > > postgresql://usern...@example.com/tablename?sslmode=require?encoding=UTF8 Who said this is a supported way to change the encoding in Postfix? In older versions of Postfix the client encoding was hardcoded to "LATIN1" as documented. > ... I'm getting this in my Postfix log: > > > Oct 21 14:17:27 backup postfix/smtpd[32279]: warning: connect to > > pgsql server postgresql://postfix:...@127.0.0.1/db?encoding=UTF8: > > invalid URI query parameter: "encoding"? The "encoding = ..." setting goes into the configuration file as a Postfix table parameter, not as a component of the connect string URI. > And setting it the "old school" way has no effect (i.e. same `LATIN1` entry > in PostgreSQL log as above): > > > hosts = postgresql://postfix:...@127.0.0.1/db > > encoding = UTF8 Are you using a version of Postfix that is 3.8 or newer? > 4: > The connection string does replace the "old school" config parameters `user > =` and `password =`, but not `dbname =`. > If I omit the (redundant) `dbname =`, I'm getting th
[pfx] Re: OpenSSL compile vs. runtime version warning
On Thu, Oct 24, 2024 at 10:50:18AM +0200, Geert Hendrickx via Postfix-users wrote: > > warning: run-time library vs. compile-time header version mismatch: > > OpenSSL 3.4.0 may not be compatible with OpenSSL 3.3.0 > > Is this warning still relevant with OpenSSL's new versioning scheme, > where OpenSSL 3.x releases are guaranteed[1] to be ABI compatible ? > > > [1] https://openssl-library.org/post/2018-09-25-version/ IIRC, this is only *forward* ABI compatibility, so an older 3.x library may not be compatible with a newer 3.y application. But otherwise, yes 3.y for (y >= x) should work. And this is the logic used in Postfix >= 3.10-20240612, but while you've upgraded to a shiny new OpenSSL, you haven't also upgraded to a shiny new Postfix snapshot. :-) -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] `postfix-pgsql`: Issues with expansion parameters `%s`, `%u` and `%d`, and some minor bugs(?)
Hi, I think I found some bugs in `postfix-pgsql` lookup, or at least the docs don't match the actual behavior. 1: The expansion parameters `%s`, `%u` and `%d` are not working as documented: If I'm just using `%s` in my query template like this: query = SELECT foo FROM mytable WHERE foo = '%s' ... then I'm getting *three* queries in my PostgreSQL log: 2024-10-21 12:38:37.556 UTC [32997] postfix@db LOG: statement: SELECT foo FROM mytable WHERE foo = 'u...@example.com' 2024-10-21 12:38:37.559 UTC [32997] postfix@db LOG: statement: SELECT foo FROM mytable WHERE foo = 'user' 2024-10-21 12:38:37.561 UTC [32997] postfix@db LOG: statement: SELECT foo FROM mytable WHERE foo = '@example.com' So it looks like if `%s` doesn't yield a result, then another try with `%u`, and a third with `%d` is made. But when using `%d` in the query template, the behavior differs in two aspects: Firstly, the same query is executed *twice*: 2024-10-21 13:00:13.914 UTC [33773] postfix@db LOG: statement: SELECT foo FROM mytable WHERE foo = 'example.com' 2024-10-21 13:00:13.916 UTC [33773] postfix@db LOG: statement: SELECT foo FROM mytable WHERE foo = 'example.com' And secondly, note the different expansions for `%d`: `@example.com` in the above queries, vs. `example.com` here. 2: This line at https://www.postfix.org/pgsql_table.5.html is wrong: hosts = postgresql://usern...@example.com/tablename?sslmode=require I guess it should be: hosts = postgresql://username:password@127.0.0.1/databasename `sslmode` isn't documented at all. 3: The encoding doesn't work as documented: The encoding used by the database client. The default setting is: encoding = UTF8 However, the default setting seems to be LATIN1 in fact, cause I'm getting this in my PostgreSQL log: 2024-10-21 12:15:07.424 UTC [31953] postfix@db LOG: statement: set client_encoding to 'LATIN1' 2024-10-21 12:15:07.428 UTC [31953] postfix@db LOG: statement: SELECT ... Furthermore, changing the encoding doesn't work - this seems to be a bug in the code (not just in the docs): When trying to append it to the connection string like that: hosts = postgresql://usern...@example.com/tablename?sslmode=require?encoding=UTF8 ... I'm getting this in my Postfix log: Oct 21 14:17:27 backup postfix/smtpd[32279]: warning: connect to pgsql server postgresql://postfix:...@127.0.0.1/db?encoding=UTF8: invalid URI query parameter: "encoding"? And setting it the "old school" way has no effect (i.e. same `LATIN1` entry in PostgreSQL log as above): hosts = postgresql://postfix:...@127.0.0.1/db encoding = UTF8 4: The connection string does replace the "old school" config parameters `user =` and `password =`, but not `dbname =`. If I omit the (redundant) `dbname =`, I'm getting this in my Postfix log: Oct 21 13:54:25 backup postfix/smtpd[30180]: fatal: /etc/postfix/postgres_db.cf: bad string length 0 < 1: dbname = 5: During testing, I stumbled across this entry in my Postfix log: Oct 21 14:56:10 backup postfix/smtpd[33373]: warning: pgsql query failed: fatal error from host postgresql://postfix:...@127.0.0.1/db: SSL connection has been closed unexpectedly? Why is an SSL connection tried to localhost? (I didn't set the `sslmode` parameter, see 2) * Postfix version: 3.7.11 * postfix-pgsql/stable,stable,now 3.7.11-0+deb12u1 amd64 [installed] * Entry in `main.cf`: local_recipient_maps = regexp:/etc/postfix/local_recipients pgsql:/etc/postfix/postgres_db.cf -- Cheers, Thomas ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: list message posting loop (was: ... smtp_tls_security_level ...)
On Thu, Oct 24, 2024 at 08:57:00AM +0200, Jaroslaw Rafa via Postfix-users wrote: > Something bad happened to the list (?), as your message seems to be repeated > multiple times, with Chinese characters prepended to the subject and list > footer appended to the body multiple times. I already (~90 minutes ago) suspended list delivery for a plausible source of the problem, and reached out to sys4.de to check their side to ensure this is resolved. What's puzzling is why Mailman fails to stop the loop, it should be able to detect that it is reposting the same message. - The Message-id is a repeat. - The "RFC5322.From:" rewrite to should mean that the reposted message is not from a list member, and should hit moderation. * Unless of course the miscreant system is somehow "undoing" the DMARC header sanitisation, and restoring the original "From" address. Perhaps a Mailman "tuneup" is possible to harden it against this sort of loop. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: smtp_tls_security_level defaults question
On Thu, Oct 24, 2024 at 16:24:04 +1100, Viktor Dukhovni via Postfix-users wrote: > Yes, of course, as documented. TLS is off by default, this is backwards- > compatible behaviour, and Postfix aims to not "surprise" operators with > unexpected new behaviour after an upgrade. This could be enabled with a compatibility_level condition? > Now perhaps at this point, we could (if Wietse concurs) change the > default security level to "may" when (almost always nowdays) TLS is > enabled at compile time. Gmail stats for TLS in/out are quite close > lately to 100% in both directions: Yes it would be good to switch to (unconditional) "may" by now. I wonder how much of that Google reported cleartext e-mail comes from Postfix... Geert ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
