Disabling delivery to local users

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Disabling delivery to local users

Marek Kozlowski-2
:-)
Well...

Let's imagine that my SMTP server is an MX for 'mydomain.tld' (and some
other ones). I've defined LDAP query for 'virtual_alias_maps', something
like:

virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf

The query file in some very simplified form can be expressed as:

server_host = ldaps://myhosthere:636
version = 3
search_base = ou=someou,o=myorg
query_filter = (mail=%s)
result_attribute = cn
result_format = %s
bind = no
dereference = 3

The intended behavior is as follows: If there is an e-mail to:

[hidden email]

LDAP query checks for all users that have the 'mail' (for example, the
name doesn't matter here) field set to '[hidden email]' and
delivers this message to those users. It works fine.

The problem is: If the 'mail' field of a user 'smithj' (there is such a
user) is NOT set to '[hidden email]' I don't want e-mails to
'[hidden email]' to be delivered to this user. I'm afraid they are :-(

May I ask for some tips what setting should I investigate?

Best regards,
Marek


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Disabling delivery to local users

Marek Kozlowski-2
As far as I can see the problem regards only mails sent from this server
(from local users). If there is a mail from a remote one it works fine,
that is:

Recipient address rejected: User unknown in local recipient table

error occurs. Hmm?

On 9/22/20 4:43 PM, Marek Kozlowski wrote:

> :-)
> Well...
>
> Let's imagine that my SMTP server is an MX for 'mydomain.tld' (and some
> other ones). I've defined LDAP query for 'virtual_alias_maps', something
> like:
>
> virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf
>
> The query file in some very simplified form can be expressed as:
>
> server_host = ldaps://myhosthere:636
> version = 3
> search_base = ou=someou,o=myorg
> query_filter = (mail=%s)
> result_attribute = cn
> result_format = %s
> bind = no
> dereference = 3
>
> The intended behavior is as follows: If there is an e-mail to:
>
> [hidden email]
>
> LDAP query checks for all users that have the 'mail' (for example, the
> name doesn't matter here) field set to '[hidden email]' and
> delivers this message to those users. It works fine.
>
> The problem is: If the 'mail' field of a user 'smithj' (there is such a
> user) is NOT set to '[hidden email]' I don't want e-mails to
> '[hidden email]' to be delivered to this user. I'm afraid they are :-(
>
> May I ask for some tips what setting should I investigate?
>
> Best regards,
> Marek
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Disabling delivery to local users

Viktor Dukhovni
In reply to this post by Marek Kozlowski-2
On Tue, Sep 22, 2020 at 04:43:22PM +0200, Marek Kozlowski wrote:

> Let's imagine that my SMTP server is an MX for 'mydomain.tld' (and some
> other ones). I've defined LDAP query for 'virtual_alias_maps', something
> like:

Tables used with virtual(5) need to implement a mapping between envelope
recipient email addresses.  Each input address rewrites to one or more
(comma,separated) output addresses, subject to the documented quoting
and escaping rules for the LHS and RHS values.

> virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf

When using LDAP as a backend for virtual(5) lookups, the LDAP query
needs to extract from each matching "entry" zero or email-address-valued
attributes, which are combined (by adding comma separators) to yield the
final result.  The address values themselves are assumed to be in valid
"external" (i.e. quoted and escaped as needed) form.

> The query file in some very simplified form can be expressed as:
>
> server_host = ldaps://myhosthere:636
> version = 3
> search_base = ou=someou,o=myorg
> query_filter = (mail=%s)
> result_attribute = cn
> result_format = %s
> bind = no
> dereference = 3

This query definition makes no sense, because in all the LDAP schemas
I'm familiar with, the "cn" attribute is just a free-form name (like
"John Smith", and is NOT an email address.  Things that are more like
an email address are:

    - mail                  (canonical email address, single-valued)
    - maildrop              (alias target, can be multi-valued)
    - mailRoutingAddress    (ditto under another name)
    - uid                   (login name without domain suffix, single-valued)

with Microsoft Exchange, the lookup key is generally matched against:

    - proxyAddresses        (input address with "smtp:" as a prefix)

In Microsoft exchange only "contact" objects have built-in
email-address-valued destination (RHS) addresses other than the primary
address.  However many sites add custom attributes for these, e.g.
"mailRoutingAddress" is somewhat popular.  Or you can use the AD
analogue of "uid" which is "sAMAccountName", which is then
domain-qualified explicitly in the result format, or implicitly with
"$myorigin".

> The intended behavior is as follows: If there is an e-mail to:
>
> [hidden email]

Which you'd match against "mail", though typically a multi-input
lookup key is more appropriate, allowing the same mailbox to be
reachable via more than one address.  Though of course one can
also create "alias" objects in LDAP with "mail" as the LHS key,
and "maildrop" (or similar) as the result attribute value.

> The problem is: If the 'mail' field of a user 'smithj' (there is such a
> user) is NOT set to '[hidden email]' I don't want e-mails to
> '[hidden email]' to be delivered to this user. I'm afraid they are :-(

Well, user "smithj" would in many an LDAP schema have "uid: smithj",
allowing you to write:

    query_filter = (&(mail=%s)(uid=%u))

if that's what you're looking for.  Of course you then still have
the problem that your result attribute is quite wrong, it should
probably be "mail", based on the description so far.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Disabling delivery to local users

Marek Kozlowski-2
:-)

First of all. The Directory structure and the config may seems a little
bit strange but, in fact, there are some important historical reasons
(backward compatibility, many, many years ago we started with Novell NDS
and NetWare4 and so on...) for having it as described. It's worth
mentioning this config has been working for many years with no problem.

>> The query file in some very simplified form can be expressed as:
>>
>> server_host = ldaps://myhosthere:636
>> version = 3
>> search_base = ou=someou,o=myorg
>> query_filter = (mail=%s)
>> result_attribute = cn
>> result_format = %s
>> bind = no
>> dereference = 3
>
> This query definition makes no sense, because in all the LDAP schemas
> I'm familiar with, the "cn" attribute is just a free-form name (like
> "John Smith", and is NOT an email address.  Things that are more like
> an email address are:
>
>      - mail                  (canonical email address, single-valued)
>      - maildrop              (alias target, can be multi-valued)
>      - mailRoutingAddress    (ditto under another name)
>      - uid                   (login name without domain suffix, single-valued)
>
> with Microsoft Exchange, the lookup key is generally matched against:
>
>      - proxyAddresses        (input address with "smtp:" as a prefix)
>
> In Microsoft exchange only "contact" objects have built-in
> email-address-valued destination (RHS) addresses other than the primary
> address.  However many sites add custom attributes for these, e.g.
> "mailRoutingAddress" is somewhat popular.  Or you can use the AD
> analogue of "uid" which is "sAMAccountName", which is then
> domain-qualified explicitly in the result format, or implicitly with
> "$myorigin".
In our case (I'm a client for LDAP; I'm not administering it) it is not:
`cn' acts as a username. `mail' is a multi-value entry. For canonicals
there is another one. Honestly:

query_filter = (mail=%s)

is a simplified form. In fact there are some ANDs and ORs but I decided
to skip it here for better clarity.

>> The intended behavior is as follows: If there is an e-mail to:
>>
>> [hidden email]
>
> Which you'd match against "mail", though typically a multi-input
> lookup key is more appropriate, allowing the same mailbox to be
> reachable via more than one address.  Though of course one can
> also create "alias" objects in LDAP with "mail" as the LHS key,
> and "maildrop" (or similar) as the result attribute value.

As I wrote in our schema `mail' is a multi-value

>> The problem is: If the 'mail' field of a user 'smithj' (there is such a
>> user) is NOT set to '[hidden email]' I don't want e-mails to
>> '[hidden email]' to be delivered to this user. I'm afraid they are :-(
>
> Well, user "smithj" would in many an LDAP schema have "uid: smithj",
> allowing you to write:
>
>      query_filter = (&(mail=%s)(uid=%u))
>
> if that's what you're looking for.  Of course you then still have
> the problem that your result attribute is quite wrong, it should
> probably be "mail", based on the description so far.
Whatever you think about this schema: I have no control over it, I'm a
client to it.
`cn' is a username
`mail' is a multi-value field.
The problem is: why for local senders if an LDAP query fails it delivers
based on user name.

Best regards,
Marek


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Disabling delivery to local users

Viktor Dukhovni
On Sat, Sep 26, 2020 at 09:08:55AM +0200, Marek Kozlowski wrote:

> First of all. The Directory structure and the config may seems a little
> bit strange but, in fact, there are some important historical reasons
> (backward compatibility, many, many years ago we started with Novell NDS
> and NetWare4 and so on...) for having it as described. It's worth
> mentioning this config has been working for many years with no problem.

Sure, OK.  Anyway, if you want to check whether the mail address matches
an account name, you can do that with a suitable "(&(cond1)(cond2))"
recipe, provided of course that LDAP has sufficient data to evaluate
a suitable combination of "cond1" and "cond2".  What Postfix can feed
into the queury are various fragments of the recipient address, as
described in ldap_table(5) and LDAP_README.

--
    Viktor.