(I'm sending again, because by mistake the message I sent before was in
html form.)
Thanks Noel, for the detailed info.
In the meantime, I had already tested, and here are the test results,
for reference (tested by removing ownership of f...@example.com by foo
and logging in (in scenario II) as user foo):
I. 1 --->a (message rejected; user asked to login), 2--->b (message
accepted; ownership not checked), 3--->a (as in 1)
The error in cases 1 and 3 is:
553 5.7.1 <f...@example.com>: Sender address rejected: not logged in
II. 1 --->b (message accepted; ownership not checked), 2--->a (message
rejected due to ownership), 3--->a (as in 2)
The error in cases 2 and 3 is:
553 5.7.1 <f...@example.com>: Sender address rejected: not owned
by user tester
So, in essence, if the client is unauthenticated, I've found that the
smtpd_sender_login_maps will never be checked directly.
The above test results differ from what you thoroughly explained in
cases I.1 and I.3, where ownership is not actually checked, yet the
message is rejected because the client is unauthenticated.
Could some other directive affect the observed differentiation?
Nick
On 11/2/2011 5:03 μμ, Noel Jones wrote:
So, for example, one client in mynetworks is trying to send as
f...@example.com, which is included in
smtpd_sender_login_maps and owned by foo. If the client is:
I. *NOT* (SASL) authenticated to postfix and we use:
1. reject_unauthenticated_sender_login_mismatch, it means that:
a/the client will be rejected unless it (SASL) authenticates or
b/the email will be accepted?
smtpd_sender_login_maps is only consulted for unauthenticated
connections.
If the user specifies a MAIL FROM listed in smtpd_sender_login_maps
and is not logged in, the mail will be rejected.
http://www.postfix.org/postconf.5.html#reject_unauthenticated_sender_login_mismatch
2. reject_authenticated_sender_login_mismatch, it means that:
a/the client will be rejected unless it (SASL) authenticates or
b/the email will be accepted?
smtpd_sender_login_maps is only consulted if the user has authenticated.
In this case (unauthenticated user, protected MAIL FROM),
smtpd_sender_login_maps is not consulted, and the mail is accepted
(but still subject to any further restrictions you define).
3. reject_sender_login_mismatch, it means that:
a/the client will be rejected unless it (SASL) authenticates or
b/the email will be accepted?
smtpd_sender_login_maps is always consulted. If the MAIL FROM is
found there, the user must use an approved authentication name.
In this case (unauthenticated user, protected MAIL FROM), the mail
would be rejected.
II. already (SASL) authenticated to postfix and we use:
1. reject_unauthenticated_sender_login_mismatch, it means that:
a/the client (SASL) login will be checked as an owner of
f...@example.com or b/it will not be checked?
smtpd_sender_login_maps is not consulted if the user has authenticated.
2. reject_authenticated_sender_login_mismatch, it means that:
a/the client (SASL) login will be checked as an owner of
f...@example.com or b/it will not be checked?
smtpd_sender_login_maps is checked to see if the authenticated user is
listed as valid for the given MAIL FROM.
3. reject_sender_login_mismatch, it means that:
a/the client (SASL) login will be checked as an owner of
f...@example.com or b/it will not be checked?
smtpd_sender_login_maps is always checked.
As an alternative (which also adds a lot of functionality), I think I
might try postfwd, which (as well as many others in the addon list
you provided) looks promising. In our case, it seems to me that a
rule to restrict the recipient address every...@example.com so that
only authenticated (SASL) login names bob and alice can send to it,
would be:
id=RS_001 ; sasl_username=!!( (bob|alice) ) ;
recipient=every...@example.com ; action=REJECT You are not allowed to
send to this address
I don't use postfwd, but that looks worth testing.
-- Noel Jones
