check_client_access using smtp auth usernames
Nikolaos Milas
offers the ability to control access to specific mail addresses using as
a key the authenticated usernames (and got no reply).
So, I am posting this as a new thread, hoping that someone has faced
this scenario.
The idea is: a user is trying to connect to our SMTP (postfix) to send
email to onemail...@example.com (which we want to control access
to). He is authenticated by postfix as userx using SASL over our LDAP
server (we are using virtual accounts only). Can we setup some
"smtp_restriction_classes" based on authenticated usernames (for example
a check_client_access lookup table with entries of the form: "userx
OK", where userx is a successfully authenticated SMTP username and not
the sender's mail address username)?
Is there direct or indirect way to accomplish this? Is there a way to
"retrieve" the SMTP authentication username and process it?
I haven't been able to locate a similar subject in the documentation
(except of course permit_sasl_authenticated which applies to all SASL
authenticated users at the same time).
Thanks very much,
Nick
Jeroen Geilman
You can restrict the sender addresses an SASL authenticated user can use
with smtpd_sender_login_maps; these senders can then be combined with
specific recipients in a restriction class.
I know of no other way to limit SASL users in this specific manner.
> Thanks very much,
> Nick
Noel Jones
> I have parenthetically asked in another - solved - thread if
> postfix offers the ability to control access to specific mail
> addresses using as a key the authenticated usernames (and got
> no reply).
>
> So, I am posting this as a new thread, hoping that someone has
> faced this scenario.
>
> The idea is: a user is trying to connect to our SMTP (postfix)
> to send email to onemail...@example.com (which we want to
> control access to). He is authenticated by postfix as userx
> using SASL over our LDAP server (we are using virtual accounts
> only). Can we setup some "smtp_restriction_classes" based on
> authenticated usernames (for example a check_client_access
> lookup table with entries of the form: "userx OK", where userx
> is a successfully authenticated SMTP username and not the
> sender's mail address username)?
>
> Is there direct or indirect way to accomplish this? Is there a
> way to "retrieve" the SMTP authentication username and process
> it?
>
> I haven't been able to locate a similar subject in the
> documentation (except of course permit_sasl_authenticated
> which applies to all SASL authenticated users at the same time).
>
> Nick
Postfix has no such feature. Maybe it would be sufficient to
limit the sender address to authenticated users with
reject_sender_login_mismatch. Then one could use
smtpd_restriction_classes that first checks for the protected
recipient, then checks for authenticated users.
http://www.postfix.org/postconf.5.html#reject_sender_login_mismatch
http://www.postfix.org/RESTRICTION_CLASS_README.html
Alternately, the sasl username is available to an external
policy service.
http://www.postfix.org/SMTPD_POLICY_README.html
Maybe an existing policy service can be configured for this.
http://www.postfix.org/addon.html#policy
-- Noel Jones
Nikolaos Milas
I checked the documentation and I think smtpd_sender_login_maps might do
the trick.
Does anyone know if a many-to-many (M-to-M) mapping is allowed in these
maps? That is, the following example is valid (a hash file)?
ma...@example.com user1
ma...@example.com user2
ma...@example.com user3
ma...@example.com user1
ma...@example.com user2
ma...@example.com user1
ma...@example.com user3
If a M-to-M relationship is allowed, what is the correct table format
(if the above is not correct)?
Thanks very much,
Nick
Ralf Hildebrandt
> Thanks Jeroen,
>
> I checked the documentation and I think smtpd_sender_login_maps might
> do the trick.
>
> Does anyone know if a many-to-many (M-to-M) mapping is allowed in
> these maps? That is, the following example is valid (a hash file)?
No
> ma...@example.com user1
> ma...@example.com user2
> ma...@example.com user3
> ma...@example.com user1
> ma...@example.com user2
> ma...@example.com user1
> ma...@example.com user3
>
> If a M-to-M relationship is allowed, what is the correct table format
> (if the above is not correct)?
That's documented:
In all cases the result of table lookup must be either "not found" or
a list of SASL login names separated by comma and/or whitespace.
--
Ralf Hildebrandt
Geschäftsbereich IT | Abteilung Netzwerk
Charité - Universitätsmedizin Berlin
Campus Benjamin Franklin
Hindenburgdamm 30 | D-12203 Berlin
Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
ralf.hil...@charite.de | http://www.charite.de
Nikolaos Milas
That means that the following format should be OK?
ma...@example.com user1,user2,user3
ma...@example.com user1,user2
ma...@example.com user1,user3
This is still a M-to-M mapping (many mail addresses are mapped to many
SASL login usernames), it's just formatted differently.
All the best,
Nick
Ralf Hildebrandt
> Thanks Ralf,
>
> That means that the following format should be OK?
>
> ma...@example.com user1,user2,user3
> ma...@example.com user1,user2
> ma...@example.com user1,user3
>
> This is still a M-to-M mapping (many mail addresses are mapped to
> many SASL login usernames), it's just formatted differently.
Yes
Nikolaos Milas
After searching for a while, I found your info/solutions were complete
and accurate.
Locking sender addresses with authenticated users appears to be a good
practice, anyway.
Here, I have two questions about reject_sender_login_mismatch:
1. If sender is in the form "f...@example.com" and (SASL) login name
is foo, will this lead to an "automatic" match (i.e. without using
smtpd_sender_login_maps) or we *always* need to define an explicit
mapping between f...@example.com and foo in smtpd_sender_login_maps?
2. About reject_unauthenticated_sender_login_mismatch: How
sender-login matching works with unauthenticated clients? Since
the client is unauthenticated (so postfix doesn't know a login
name associated with the current client) how can postfix match
sender address with login name? It will have to drop all these
connections?
Please, clarify.
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 ever...@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=ever...@example.com ; action=REJECT You are not allowed to
send to this address
It appears intuitive and the rule "language" is rich.
Any comments?
Thanks again for your valuable advice.
All the best,
Nick
Reindl Harald
Am 11.02.2011 10:08, schrieb Nikolaos Milas:
> Thank you Noel,
>
> After searching for a while, I found your info/solutions were complete and accurate.
>
> Locking sender addresses with authenticated users appears to be a good practice, anyway.
>
> Here, I have two questions about reject_sender_login_mismatch:
>
> 1. If sender is in the form "f...@example.com" and (SASL) login name
> is foo, will this lead to an "automatic" match (i.e. without using
> smtpd_sender_login_maps) or we *always* need to define an explicit
> mapping between f...@example.com and foo in smtpd_sender_login_maps?
there is nothing automatic, even if login-name is the same
as the mail-address
> 2. About reject_unauthenticated_sender_login_mismatch: How
> sender-login matching works with unauthenticated clients? Since
> the client is unauthenticated (so postfix doesn't know a login
> name associated with the current client) how can postfix match
> sender address with login name? It will have to drop all these
> connections?
Unauthenticated clients do not interest here because they do not relay
"reject_unauthenticated_sender_login_mismatch" means that mails from
outside are no problem (other smtp-servers deliver mails to you)
but your users can not send with any address they want
If you make sure your server is not a open-relay all is fine
Nikolaos Milas
Please, let me ask for some clarifications, cause I'm confused:
If we have (SASL) UNauthenticated clients (who are allowed to send
emails from mynetworks) AND (SASL) authenticated clients (in mynetworks
or anywhere), what will happen to our UNauthenticated clients (in
mynetworks) when they try to use as a sender a mail address included in
smtpd_sender_login_maps? They will be allowed to send or not?
So, for example, one client in mynetworks is trying to send as
f...@example.com, which is included in smtpd_sender_login_mapsand owned
by foo. Ifthe 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?
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?
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?
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?
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?
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?
Please clarify.
Thanks,
Nick.
Noel Jones
> Thank you Harald,
>
> Please, let me ask for some clarifications, cause I'm confused:
>
> If we have (SASL) UNauthenticated clients (who are allowed to
> send emails from mynetworks) AND (SASL) authenticated clients
> (in mynetworks or anywhere), what will happen to our
> UNauthenticated clients (in mynetworks) when they try to use
> as a sender a mail address included in
> smtpd_sender_login_maps? They will be allowed to send or not?
>
> So, for example, one client in mynetworks is trying to send as
> f...@example.com, which is included in
> smtpd_sender_login_mapsand owned by foo. Ifthe 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 ever...@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=ever...@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
Nikolaos Milas
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:
Nikolaos Milas
Now that I re-read your last post, I can see there is no discrepancy at
all between my findings and your description in the two cases I mentioned.
In fact, what happens is exactly what you describe. The email message is
rejected because the client specifies a MAIL FROM listed in
smtpd_sender_login_maps and the client is not logged in.
I mis-interpreted your explanation and thought you meant that the client
was rejected after examination of ownership in smtpd_sender_login_maps,
while in fact ownership is not checked. Your explanation was accurate.
Sorry for the complication, and thanks again for your detailed analysis.
I believe this explanation should find its way into the documentation,
because I am afraid the explanation of the three directives is otherwise
obscure.
All the best,
Nick