On Sun, Nov 24, 2024 at 03:09:06PM +0100, Thomas Landauer via Postfix-users wrote:
> * First is a question: > Is default_delivery_status_filter affecting Postfix's messages (a) in the > SMTP session, (b) in the logfile, and/or (c) in DSNs? As promised, it modifies the delivery status, which may be logged, or copied in bounces or affected whether a message is bounced or deferred. > I can't see any difference in (a) and (b), so I guess it's (c) only?! => > Please add that to > https://www.postfix.org/postconf.5.html#default_delivery_status_filter No, it is as documented, none of the above. > * At https://www.postfix.org/postconf.5.html#debug_peer_level please add > allowed values: 0?, 1, 2, 3?,... Being an *increment*, it should not be surprsing that it must be strictly positive. Sufficiently large values are naturally indistinguishable. > * At https://www.postfix.org/postconf.5.html#smtp_tls_security_level and > https://www.postfix.org/postconf.5.html#smtpd_tls_security_level is the > default really empty? Or `none`? The text directly below the default (empty) value reads: The default SMTP TLS security level for the Postfix SMTP client. When a non-empty value is specified, this overrides the obsolete parameters smtp_use_tls, smtp_enforce_tls, and smtp_tls_enforce_peername; when no value is specified for smtp_tls_enforce_peername or the obsolete parameters, the default SMTP TLS security level is none. Unclear why you're inclined to doubt the docs. > If empty, then please add what this means in contrast to `none`. See above, "When a non-empty ...", otherwise the obsolete parameters are in effect, unless they also fall through to the last-resort default. > * I would suggest to add a trailing semicolon to all lookup SQL examples > (e.g. at https://www.postfix.org/PGSQL_README.html and > https://www.postfix.org/pgsql_table.5.html). It is not needed. The table driver issues a single query. > But without one, it's easier to run an SQL injection with a string like: > 1; DELETE FROM users; > > This is probably not possible anyway, but closing the statement with a > semicolon looks even more secure and certainly won't do any harm, so I think > it's a good idea to show this as best practice. Sorry, no. -- Viktor. _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
