https://www.postfix.org/SASL_README.html
Use case: local submissions - port 465, Cyrus SASL with sasldb, .local domain
with dnsmasq, and TLS
1) The section "Cyrus SASL Plugins - auxiliary property plugins" is out of
place, with the "Plugin" table shown separately and far after the "backend"
table, as if it is a separate thing, and not the *same* thing. The hierarchy
presented is misdirecting, since what follows is really three types of
"saslauthd" and then three types of "plugins". Even more confusing, the
section "Testing saslauthd authentication" is shown *preceding* the "Plugins"
section.
The "testing" section should be shown *after* all of the configuration sections.
2) Under the section "The sasldb plugin", the statement "Important - users must
specify usern...@example.com as login name, not username." is not strictly
true, and thereby, misleading, at best. Additionally, the statement itself
contradicts the immediately preceding example: "saslpasswd2 -c -u example.com
username". Even worse, the database produced will fail the earlier test method
shown.
Actually, the "realm", so called in the "testsaslauthd" command man page, and
confusingly also called the "domain" in the saslpasswd2 command man page, is an
essential component of the sasldb plugin. It defaults to the value returned by
"hostname" on the system, and generally should be set explicitly, exactly as
shown in the "saslpasswd2" example.
However, in the "testsaslauthd" command, the "realm" must *also* be explicitly
provided, or the test will fail. The testing example *should* be:
----
testsaslauthd -u username -p password -r example.com
----
Furthermore, the same considerations with regard to "realm"/"domain" apply in
the postfix configuration, where the "realm" should be set explicitly with
----
-o smtpd_sasl_local_domain=$mydomain
----
Otherwise, the SASL client actually would have to provide an explicit
"usern...@example.com" in place of "username", which is needless and confusing
for the user.
Also, there could be a little more "hand-holding" in the SASL_README, since the
sasldb plugin is almost entirely without documentation on the internet,
especially given the confusing, seemingly contradictory, explanation at "man 8
saslauthd":
----
sasldb (All platforms)
Authenticate against the SASL authentication database. Note that this is
probably not what you want to use, and is even disabled at compile-time by
default. If you want to use sasldb with the SASL library, you probably want to
use the pwcheck_method of "auxprop" along with the sasldb auxprop plugin
instead.
----
With Arch Linux, the command "pluginviewer -a" gives only:
----
Installed and properly configured auxprop mechanisms are:
sasldb List of auxprop plugins follows
Plugin "sasldb" , API version: 8
supports store: yes
----
At the least, this page gives a little more perspective on "sasldb":
https://web.mit.edu/darwin/src/modules/passwordserver_sasl/cyrus_sasl/doc/sysadmin.html
Nonetheless, this one statement is useful, at
https://www.cyrusimap.org/sasl/sasl/sysadmin.html
"Realms are represented in a username string by any text following the ‘@’
sign." However, the subsequent statement on that page is false, at least in
some contexts: "If no realm is provided, the server’s FQDN is assumed (likewise
when specifying a realm for saslpasswd2)." Actually, the value returned by
"hostname" is used, not the FQDN.
Also, it is important to explain the link between postfix and the Cyrus SASL
configuration given by "postconf smtpd_sasl_path", which has "smtpd_sasl_path =
smtpd", and the directory implied by "cyrus_sasl_config_path = ", which
defaults to "/etc/sasl2/", and then the fundamental role of the implied file
"/etc/sasl2/smtpd.conf". All of that is extremely important to understanding
sasldb, and not at all obvious or sufficiently documented.
Finally, it seems best to repeat the warning under the "saslauthd" section,
also for the "sasldb" section: "Do not specify any other mechanisms in
mech_list than PLAIN or LOGIN". I cannot find any documentation to suggest
that sasldb will support anything other than the PLAIN and LOGIN mechanisms.
That conflicts with the example given, which has "mech_list: PLAIN LOGIN
CRAM-MD5 DIGEST-MD5 NTLM", despite the subsequent, effectively useless warning,
without recourse to documentation, "In the above example adjust mech_list to
the mechanisms that are applicable for your environment."
3) In the postfix configuration, SASL will not even work when the postfix
"restrictions" otherwise fail. And those restrictions become confusing with
the statement in https://www.postfix.org/SMTPD_ACCESS_README.html:
----
Each restriction list is evaluated from left to right until some restriction
produces a result of PERMIT, REJECT or DEFER (try again later). The end of each
list is equivalent to a PERMIT result. By placing a PERMIT restriction before a
REJECT restriction you can make exceptions for specific clients or users. This
is called allowlisting; the smtpd_relay_restrictions example above allows mail
from local networks, and from SASL authenticated clients, but otherwise rejects
mail to arbitrary destinations.
----
Specifically, when using "-o
smtpd_client_restrictions=reject_unknown_client_hostname,permit_sasl_authenticated,reject",
the "sasl authentication" will never happen, and access will fail immediately
with "reject", *except* when using the default "smtpd_delay_reject = yes".
This is not at all obvious, because of the following distinction:
It might be suppose, erroneously, from the statement "By placing a PERMIT
restriction before a REJECT restriction you can make exceptions for specific
clients or users", that with "permit_sasl_authenticated,reject" sequence, the
"permit_sasl_authenticated" would *always* be performed *before* the "reject"
test would be applied.
That is not the way it works! And, not sufficiently documented!
Instead, apparently, the "permit_sasl_authenticated,reject" test is *presumed*
to have already been performed - and it has not, so "fail" - and when then the
"reject" test is performed - which succeeds - the result is "reject", "554",
and the SASL auth never actually happens.
In particular, note the example at
https://www.postfix.org/SMTPD_ACCESS_README.html:
----
/etc/postfix/main.cf:
# Allow connections from trusted networks only.
smtpd_client_restrictions = permit_mynetworks, reject
----
There are two possible solutions:
a) place the "reject" test much later, in "smtpd_recipient_restrictions", or
b) leave the default "smtpd_delay_reject = yes".
This *immediate* evaluation of, in particular, "permit_sasl_authenticated"
should be explained in the "Delayed evaluation of SMTP access restriction
lists" section of https://www.postfix.org/SMTPD_ACCESS_README.html#timing
Still, apparently, with "smtpd_delay_reject = yes", and "-o
smtpd_client_restrictions=permit_sasl_authenticated,reject", the
"permit_sasl_authenticated" will have to be *repeated* at "-o
smtpd_relay_restrictions=permit_sasl_authenticated", which, even then, by
itself is not enough, because "fatal: in parameter smtpd_relay_restrictions or
smtpd_recipient_restrictions, specify at least one working instance of:
reject_unauth_destination, defer_unauth_destination, reject, defer,
defer_if_permit or check_relay_domains". So then, "-o
smtpd_relay_restrictions=permit_sasl_authenticated,reject_unauth_destination"
is one solution.
4) When using "-o smtpd_client_restrictions=reject_unknown_client_hostname"
with local "dnsmasq", a resulting
----
postfix/submissions/smtpd[2255077]: warning: hostname jade.local does not
resolve to address 10.44.33.22
----
will be just plain misdirection, when actually, "jade.local" *does* resolve to
the correct address.
When viewing the packet history, it is seen that, in fact, postfix *first* does
an SOA lookup on the "local" domain. If that SOA lookup fails, that "does not
resolve" warning is given, which is, in fact, wrong.
This SOA lookup should be documented!
When using dnsmasq, an explicit SOA configuration is needed, so that there is:
----
host-record=jade.local,10.44.33.22
auth-zone=local
auth-server=local
----
5) The example in the "Testing SASL authentication in the Postfix SMTP Server"
section in https://www.postfix.org/SASL_README.html
----
openssl s_client -connect server.example.com:25 -starttls smtp
----
is misleading, where submissions, port 465, instead requires
----
openssl s_client -connect server.example.com:465
----
without the "-starttls smtp" switch, which will cause the negotiation to hang
immediately after "CONNECTED(00000003)".
This should be documented under "Testing SASL authentication in the Postfix
SMTP Server" as a separate example!
6) "-o smtpd_sender_restrictions=reject_authenticated_sender_login_mismatch" is
quite confusing.
----
Reject the request when the client is authenticated with SASL, but either the
MAIL FROM address is not listed in $smtpd_sender_login_maps, OR the SASL login
name [ja...@nurealm.net] is not an owner for that address [ja...@nurealm.net
???].
----
The log shows:
----
postfix/submissions/smtpd[2454047]: NOQUEUE: reject: RCPT from
jade.local[10.44.33.22]: 553 5.7.1 <ja...@nurealm.net>: Sender address
rejected: not owned by user ja...@nurealm.net; from=<ja...@nurealm.net>
to=<postfix-users@postfix.org> proto=ESMTP helo=<jade.local>
sasl_method=PLAIN sasl_username=ja...@nurealm.net
----
Then, in what way is "sasl_username=ja...@nurealm.net" *not* the owner of the
address "from=<ja...@nurealm.net>"?
Also, the format of entries in the optional "smtpd_sender_login_maps" is
entirely unclear. Please give a working instance example for an "inline:"
database.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
