Email users bypass Reject sender and login mismatch

Discussion in 'Installation/Configuration' started by Kovacs Andras, Jan 19, 2022.

  1. Kovacs Andras

    Kovacs Andras New Member

    Hi there,

    I want to prevent every user to spoof sender address.
    It is done by enabling the "Reject sender and login mismatch" option.

    However I need some specific email account to be able to send from any existing address, but only within its own domain.

    Example:
    I have email accounts user1@domain, user2@domain and relay@domain.
    user3@domain does not exists.
    user1@domain and user2@domain can only send from their own address. It's clear.

    relay@domain need to send from user1@domain and user2@domain but not from user3@domain or user@otherdomain.

    Is it possible to set this in postfix?

    Thanks!
     
    Last edited: Jan 19, 2022
  2. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

    That shouldn't be too difficult as you know exactly what you want. You could consider/test changing smtpd_sender_restrictions to put reject_unlisted_sender ahead of permit_sasl_authenticated. If that doesn't do what you want, you could just add a new map to smtpd_sender_login_maps to explicitly list what addresses relay@domain can send as.

    Remember that whatever you end up changing in /etc/postfix/main.cf should also be made to /usr/local/ispconfig/server/conf-custom/install/postfix_custom.conf.master so your changes persist future ISPConfig updates.
     
  3. Kovacs Andras

    Kovacs Andras New Member

    smtpd_reject_unlisted_sender is enabled by default and as I understand this restriction is applied to all senders.

    I tried to add a regexp map to smtpd_sender_login_maps which returns the relay@domain address for any address with @domain.
    The problem is that postfix seems to use these maps on a first match basis. If it finds a match in one map, it will not search any of the following maps. So regexp will not work, because it will return relay@domain for every @domain address, so only relay@domain will be allowed to send mail from @domain addresses, the actual owner of the address will not.
    I should put every email address one by one to the new map, but that is not maintainable.

    I found two possible solution:

    1. I create a new table in dbispconfig with domains and the "universal sender" address(es), and change the sql query in mysql-virtual_sender_login_maps.cf to include the universal sender address.
    Question: Can the database change (new table) persist through updates?
    For the modified query I think I can use a mysql-virtual_sender_login_maps.cf.master file.

    2. I add another sql map to smtpd_sender_login_maps with modified (and probably overcomplicated) query, which returns answer only for the domains in question, and add the universal sender to the query as static value.
    This is harder to maintain, but can persist with a simple postfix_custom.conf.master file.
     
  4. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

    FWIW, ISPConfig explicitly sets 'smtpd_reject_unlisted_sender = no'; you might ensure your custom templates are up to date (for postfix, you can/should usually remove a custom template for the entire postfix config, and only put your changes into postfix_custom.conf.master).
    This is correct. If the list of users is small I would just manually create it; if it's large or changes frequently, and sql lookup is the way to go. Either of your solutions should work.
    Yes, your custom table will remain untouched. Another option would be to add a custom column to mail_user (and/or mail_forwarding) to flag these "universal senders", and alter the queries to use those fields. Custom columns will persist as well and shouldn't cause any issue in ISPConfig (if you find any that do, we should fix that in ISPConfig).
     
  5. Kovacs Andras

    Kovacs Andras New Member

    I probably just changed it on that particular server I used for testing. I was unaware this change, thank you for pointing out.

    Custom table will be the solution.
    This seems too marginal to me to put up a feature request, but I think I will put together a module to manage the addresses in that table from ISPConfig interface.

    Thanks.
     

Share This Page