On Fri, Sep 18, 2020 at 07:01:26PM +0300, Janis wrote:

> What I would like to achieve is to permit sender to set "mail from" the 
> same value as his SASL auth username or some specially allowed "alias 
> e-mail" addresses that are defined somewhere. For example, if user1 is 
> allowed to respond for his company, he would authenticate as 
> us...@domain.tld and could set "mail from" 1) us...@domain.tld or 2) 
> i...@domain.tld.
> 
> I can achieve this at the moment by writing both lines in login_maps 
> file, but it feels kind of wrong way to do things. Is there a way not to 
> duplicate Dovecot usernames and permit 1st case restriction in "mail 
> from" something like permit_sasl_username_as_mail_from?
>
> I was looking directly at 
> http://www.postfix.org/postconf.5.html#smtpd_sender_restrictions, but 
> none of the options seemed right for this use case.

Did you also look at:

    <http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps>?

That text reads in part:

    Optional lookup table with the SASL login names that own the sender
    (MAIL FROM) addresses.

    Specify zero or more "type:name" lookup tables, separated by
            --------------------------------------
    whitespace or comma. Tables will be searched in the specified order
    until a match is found. With lookups from indexed files such as DB
    or DBM, or from networked tables such as NIS, LDAP or SQL, the
    following search operations are done with a sender address of
    user@domain: 

Therefore, you can use:

    main.cf:
        indexed = ${default_database_type}:${config_directory}/
        pcre = pcre:${config_directory}/
        smpd_sender_login_maps =
            ${pcre}same-as-sender.pcre,
            ${indexed}adhoc

    same-as-sender.pcre:
        # us...@example.org us...@example.org
        /^(.*)$/        $1

    adhoc:
        # All the users allowed to send as "info@..."
        i...@example.org us...@example.org, us...@example.org, ...
        
> Maybe if i scratched 
> my head a bit, i could come up with some "tricky" SQL query as a 
> workaround and use reject_sender_login_mismatch, but maybe i have just 
> overlooked some simple setting, thus i ask for any input.

SQL can be a good option if it meshes well with the provisioning process
and the list of adhoc mappings is fairly dynamic.

-- 
    Viktor.

Reply via email to