On 2022-05-05 at 09:17:30 UTC-0400 (Thu, 5 May 2022 15:17:30 +0200)
Matus UHLAR - fantomas <[email protected]>
is rumored to have said:
On 2022-05-04 at 12:20:49 UTC-0400 (Wed, 4 May 2022 18:20:49 +0200)
Matus UHLAR - fantomas <[email protected]>
is rumored to have said:
I have tried to restrict users only to be able to send mail with
their own e-mail addresses.
(I am aware of difference between envelope from: and header From:
but I have to start somewhere).
after reading smtpd_sender_login_maps and
reject_sender_login_mismatch I thought I need to map all protected I
have set up:
smtpd_sender_restrictions =
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_sender_login_mismatch
what I see in logs:
May 1 02:04:15 fantomas postfix/smtpd[31415]: warning: restriction
`reject_authenticated_sender_login_mismatch' ignored: no SASL
support
May 1 02:04:15 fantomas postfix/smtpd[31415]: warning: restriction
`reject_unauthenticated_sender_login_mismatch' ignored: no SASL
support
1.
- do I need to explicitly enable SASL on port 25 in order to be able
to regulate the sender addresses for users?
On 04.05.22 13:59, Bill Cole wrote:
To regulate the sender address based on a SASL authentication
identity, you need to know a SASL authentication identity.
how does reject_unauthenticated_sender_login_mismatch work then?
By knowing that there is no authentication identity. It's a degenerate
case, for which I don't really understand any justification.
does it only work when authentication is enabled but the user hasn't
authenticated?
That is my understanding, but I have not tested it in depth.
Typically you will not support SASL authentication on port 25 because
port 25 is for mail from non-local, unfamiliar senders.
I guess this is why I haven't SASL enabled on port 25 :-)
perhaps I could enable authentication via smtpd_sasl_auth_enable while
disabling it by having AUTH in smtpd_discard_ehlo_keywords and
smtpd_command_filter?
I'm lost as to WHY you want to use a login mismatch test on a service
with no logins. There are better ways to control inbound forgeries.
isn't this what reject_unauthenticated_sender_login_mismatch does?
reject_unauthenticated_sender_login_mismatch enforces the
restrictions defined in smtpd_sender_login_maps only against
unauthenticated clients, so smtpd_sender_login_maps is really just a
list of sender addresses that require authentication, but don't care
about the SASL AuthID.
as I said, the clients on port 25 are unauthenticated - that's why I'm
curious why smtpd complaind about no SASL support.
Also why I'm curious why you're trying to use a restriction that is
defined as requiring authentication IDs.
2. reject_sender_login_mismatch
Reject the request when $smtpd_sender_login_maps specifies an
owner for the MAIL FROM address, but the client is not (SASL) logged
in as that MAIL FROM address owner; or when the client is (SASL)
logged in, but the client login name doesn't own the MAIL FROM
address according to $smtpd_sender_login_maps.
- do I understand this correctly as two alternative ways of
explaining
"you can send mail from [email protected] only if it's in
smtpd_sender_login_maps and lists your username"?
Yes, but it is a bit more precise in describing both the case where
the user has authenticated and the case where they have not. Note
that a sender address that is listed may ONLY be used by an
authenticated user, and that unauthenticated users are rejected if
they try to send as any listed sender.
so it's "not logged in as the owner or logged in, not as the owner".
Since I got the two messages above by using single
reject_sender_login_mismatch, I assume it behaves as using both
reject_unauthenticated_sender_login_mismatch +
reject_authenticated_sender_login_mismatch
I was just curious if it has meaning I haven't seen.
It is very rare for any Postfix feature to exhibit undocumented
user-visible behavior.
3. reject_known_sender_login_mismatch
Apply the reject_sender_login_mismatch restriction only to MAIL
FROM addresses that are known in $smtpd_sender_login_maps. This
feature is available in Postfix version 2.11 and later.
- how is this different from other reject_*sender_login_mismatch?
This only rejects mismatches of *known* sender addresses. It will not
reject users sending mail from a sender address not listed at all in
$smtpd_sender_login_maps.
so, reject_known_sender_login_mismatch only handles addresses listed
in smtpd_sender_login_maps
while reject_sender_login_mismatch handles addresses not listed there
there?
Yes.
which are they?
Addresses you don't know about. Non-existent addresses. Addresses you
haven't set up a mapping for.
Is there e.g. a default mapping like "[email protected]
[email protected]" that allows using address equal to own username
then?
I see no indication of that in any documentation.
It is very rare for any Postfix feature to exhibit undocumented
user-visible behavior.
It is worth noting that there is no fundamental requirement for
authentication identities to resemble email addresses or that when they
do, they be generally mailable. The use of 'user@domain' authentication
identities for SMTP AUTH is just the obvious simplest approach, not a
requirement. It is entirely reasonable by the spec to use bare 'user' or
'user@domain@authrealm' identities, and for those to have no
programmatic equivalence to mailable addresses.
--
Bill Cole
[email protected] or [email protected]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
