Hello,
DATABASE_README mentions netinfo, nis, nisplus. The manual page “postconf(1)
-m” does not.
DATABASE_README lists pipemap and pgsql in reversed alphabetical order.
Likewise for lmdb and ldap in DATABASE_README and “postconf(1) -m”.
> postmap(1): The postmap(1) command can query any supported file type, but it
> can create only the following file types:
> fail A table that reliably fails all requests. The lookup table name is
> used for logging only. This table exists to simplify Postfix error tests.
The above wording is also used in postalias(1).
Indeed $(postmap fail:zzz) does complain, if the file zzz is missing. But if
the file is present and empty, $(postmap fail:zzz) does not write anything to
it. To be precise, running $(strace postmap fail:zzz) prints:
openat(AT_FDCWD, "zzz", O_RDONLY) = 4
newfstatat(4, "", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_EMPTY_PATH) = 0
umask(033) = 022
getuid() = 0
geteuid() = 0
getegid() = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
umask(022) = 033
read(4, "", 4096) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
close(4) = 0
$(postmap -q uu fail:zzz) does fail as expected, and running it under strace
shows that the command does not verify if the file zzz is present or absent.
Provided that for fail:zzz queries the file zzz is not considered anyhow, what
is the point in stating, that “postmap can create the following file types: …
fail …”?
In FILTER_README the paragraph “Note: In this time of mail worms and forged
spam…” appears twice. Having it only once is sufficient. In fact the two
mentions are not very identical: the one speaks about BAD IDEA, the other about
VERY BAD IDEA. Likewise VERP_README spells twice that the former «sendmail
-V+=» is now «sendmail -XV+=». ADDRESS_VERIFICATION_README contains twice the
text between “The reject_unknown_recipient_domain restriction” and „… probe
fails with some temporary error.“
As a person, who wants to understand Postfix by reading the documentation, I
prefer not to have the same information repeated several times on the same
page. I know this is subjective.
Per HISTORY-20220121 the file CYRUS_README is deleted, but it is still
mentioned in VIRTUAL_README. $(grep CYRUS_README) finds more places.
SASL_README says for Cyrus SASL: mech_list: Do not specify any other mechanisms
in mech_list other than PLAIN or LOGIN when using saslauthd! It can only
handle these two mechanisms, and authentication will fail if clients are
allowed to chose other mechanisms.
Upstream Cyrus SASL has removed support for LOGIN:
https://github.com/cyrusimap/cyrus-sasl/issues/791 ⇔
https://github.com/cyrusimap/cyrus-sasl/commit/a5569579233051bb2e736d2ef3a8c92eb970ffb0
.
I use Cyrus IMAP and Sendmail with Cyrus SASL and pwcheck_method: saslauthd and
mech_list: PLAIN GSSAPI. GSSAPI did work when I configured it and I have not
tried it recently. So if the Cyrus SASL callbacks are implemented properly
(whatever this means) in Postfix/Cyrus IMAP/Sendmail, when using $(saslauthd -a
pam -r), thus when the password is not available in clear text, and PAM is
configured to use pam_krb5.so, GSSAPI authentication does work. I configured
this long time ago, so I cannot
say how exactly I did it.
Why is it written, that Postfix with saslauthd cannot work for method GSSAPI?
In SASL_README - auxiliary property plugins - are mentioned CRAM-MD5,
DIGEST-MD5 and NTLM. These are removed from upstream Cyrus SASL, but nobody
can say when a Cyrus SASL release can be expected without these plugins (
https://cyrus.topicbox.com/groups/devel/T66fe90bb03c0fd20/estimated-release-date-for-cyrus-sasl-without-kerberos-iv-ntlm-cram-md5-digest-md5
) . The documentation should use instead the SCRAM plugins. The section
“Building the Cyrus SASL library” suggests calling “./configure
--enable-login --enable-ntlm” - it will not work on the master branch of Cyrus
SASL.
I suggest replacing in SASL_README.html <code>libsasl</code> with
<code>libsasl2</code>, as newer software uses libsasl2 and not libsas1.
In ADDRESS_VERIFICATION_README, line 384, It’s no good → It’s not good
In MULTI_INSTANCE_README line 95 (remove WITH): This server has with a
null-client
Postfix instance for local submission, an input Postfix instance to receive
mail from the Internet, plus an advanced SMTP content-filter and an output
Postfix instance to deliver filtered email to its internal destination.
TLS_README, line 372 (the one with OE) there is no closing bracket: This is
true for OE (Win32 < 5.0 and Win32 >=5.0 when run on a port<>25 and OE (5.01
Mac on all ports).
VERP_README line 153: The Postfix sendmail command has a -V flag to request
VERP style delivery.
This should be -XV as this is what newer versions use.
Greetings
Дилян
_______________________________________________
Postfix-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
