Postfix/AMaViS: no_address_mappings

  • I am confused about a specific setting for AMaViS.


    When installing i-MSCP the master.cf changes in a way I don't understand.


    My current setup (only line in question included)

    Code
    1. localhost:10025 inet n - n - - smtpd -o smtpd_override_options=no_address_mappings


    With i-MSCP this line gets commented

    Code
    1. localhost:10025 inet n - n - - smtpd
    2. # -o smtpd_override_options=no_address_mappings


    I cannot find this setting in Postfix docs at all so I am wondering if this actually has an effect at all. Why is it there in i-MSCP but deactivated?


  • Hello ;


    In i-MSCP master.cf we have:


    Code
    1. # Uncomment the second line below when using AMaViS
    2. smtp inet n - - - - smtpd
    3. # -o receive_override_options=no_address_mappings


    It's clearly stated that you must uncomment the line if you are using AMaViS.


    BTW: http://www.postfix.org/postconf.5.html#no_address_mappings

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    Edited once, last by Nuxwin ().

  • Hi Nuxwin,


    my question was not about the receive_override_options for the smtp service, but about the smtpd_override_options for the AMaVis return service on port 10025.


    The first one is clear to me, and as you say it is documented in the config, but the second one is not.





    But there is another thing about receive_override_options the which is confusing too. Several documentations mention that one should add receive_override_options again to to the 10025 service to enable the previously disabled no_address_mappings.


    http://www.postfix.org/FILTER_README.html (they use port 10026 and not 10025 but the usage is the same)

    Code
    1. localhost:10026 inet n - n - 10 smtpd -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_milters


    Quote


    The "-o receive_override_options" overrides main.cf settings to avoid duplicating work that was already done before the content filter. These options are complementary to the options that are specified in main.cf:
    We don't specify "no_address_mappings" here. This enables virtual alias expansion, canonical mappings, address masquerading, and other address mappings after the content filter. The main.cf setting of "receive_override_options" disables these mappings before the content filter.


    http://workaround.org/ispmail/…iltering-spam-and-viruses

    Code
    1. 127.0.0.1:10025 inet n - - - - smtpd
    2. -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks


    Quote


    Now two settings here deserve an explanation. First the receive_override_options are set to no_address_mappings. This disables all address mappings. Your virtual aliases for example are not considered at first. Then the email is sent to smtp-amavis and in the end returned to the 127.0.0.1:10025 service that sets a lot of options. One of those options is the receive_override_options again. But this time the no_address_mappings setting is left out. So at this stage Postfix finally checks your virtual aliases. Sounds complicated? Well, it has to be done like this or otherwise your aliases would be evaluated twice which leads to mails sent twice. The other options are used to disable checks that Postfix has already done during the first stage.

  • Ok, just found the reason why the line is now commented:
    http://trac.i-mscp.net/ticket/408
    https://github.com/i-MSCP/imsc…88afb26cbe541e8436613da95



    However I think I found a related bug. Mail delivered through the pickup service (local) duplicates mails on forwarded mail accounts.


    You can reproduce it:
    - Activate Amavis
    - Create [email protected]
    - Create [email protected] and forward it to [email protected]
    - Using "mail [email protected]" from the console send a mail to the address


    The mail will be in [email protected] 2 times.
    So, either disable content filtering for the pickup service, or add no_address_mappings
    I created a bug: http://trac.i-mscp.net/ticket/823


    Anyway, I still do not understand the "-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks" which is added to the 10025 service (see links in previous posts)


    According to those websites this setting is important to activate the previously disabled address mapping again. But even without it, it seems to work.

  • The parameter is unused if you did not use AMaViS.
    So it is correct to comment this line. If you use AMaViS, you need both lines.
    Otherwise you will receive 2 email for the forwarder!


    More information you will find here: http://workaround.org/ispmail/etch (Step 10: AMaViS: Filtering spam and viruses)

    Edited once, last by TheCry ().

  • I just saw the commit that was made today:
    https://github.com/i-MSCP/imsc…fa17e1933d7151a8e4527b745


    What are the implications of having the receive_override_options=no_address_mappings set globally instead of only on the required services? For sure that solves the problem when you have additional services like the submission or local pickup. But are there no side effects? Anyway, if defined global it could be removed from the master.cf completely, right?



    Regarding the receive_override_options on 10025: I could not find any differences if this option is on or off. Both settings work.
    The official documentation contains the setting, but there is no specific explanation there.
    There is just the following hint for all the not explained settings:


    All remaining options either configure the dedicated smtpd-daemon to be more failure tolerant or exist to avoid unnecessary use of resources.


    http://www.ijs.si/software/amavisd/README.postfix.html


  • Hello ;


    All is well explained here http://workaround.org/ispmail/…iltering-spam-and-viruses .


    Anyway, since we can now hook into the i-MSCP core, I'm wondering if I will not remove all these parameters and let a plugin take care of them. I'll talk with my team to take a decision.


    Thank you for using i-MSCP

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206


  • Yes, I know this page, but
    1. the place where the address mapping is enabled is different from the official amavis documentation which places it at the incoming services instead of the global file. Like it was before todays commit (and still is as a duplicate)
    2. Both this page and the official doc use the override options again on the amavis return service. This one is missing in the current commit



    http://www.amavis.org/README.postfix.html
    http://www.amavis.org/README.postfix.old



    Anyway, since we can now hook into the i-MSCP core, I'm wondering if I will not remove all these parameters and let a plugin take care of them. I'll talk with my team to take a decision.


    Sounds good. :) I understand that Amavis is not part of i-mscp, but either provide correct settings or none of them. The current configs suggest that removing the comment on the 2 lines is enough, but as the links above show, it is not ;)

    Edited once, last by MuhKuh ().


  • http://www.postfix.org/FILTER_README.html


    You are thinking about incoming only. We are thinking about both incoming and outgoing.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    Edited once, last by Nuxwin ().


  • You are thinking about incoming only. We are thinking about both incoming and outgoing.


    From Postfix view all mails are incoming and outgoing (except if filtered and not delivered) and therefore it is enough to filter at the incoming end once.


    And there are only a few incoming ports to postfix. It does not matter if the user sends a mail using the postfix server to someone on the outside world, or if postfix receives the mail and delivers it to the local mailbox. In both cases the incoming port is smtp port 25.
    But: You have to consider all possible input ports. And this includes SSL and local pickup service.
    I am just saying I don't know what's the possible side effect of having the "receive_override_options = no_address_mappings" defined in the global main.cf
    Perhaps none, and it saves some more lines in the master.cf. Not sure :)


    And for the "-o receive_override_options=no_unknown_recipient_checks,no_header_body_checks" on port 10025 which is currently missing, the documentation you just linked says:

    Quote


    The "-o receive_override_options" overrides main.cf settings to avoid duplicating work that was already done before the content filter. These options are complementary to the options that are specified in main.cf:

    • We specify "no_unknown_recipient_checks" to disable attempts to find out if a recipient is unknown.
    • We specify "no_header_body_checks" to disable header/body checks.
    • We specify "no_milters" to disable Milter applications (this option is available only in Postfix 2.3 and later)
    • We don't specify "no_address_mappings" here. This enables virtual alias expansion, canonical mappings, address masquerading, and other address mappings after the content filter. The main.cf setting of "receive_override_options" disables these mappings before the content filter.