[Resolved] Amavis used even if not installed (new install but migrated mailboxes)

Discussion in 'Installation/Configuration' started by blackangel, Mar 31, 2022.

  1. blackangel

    blackangel New Member

    Hello.

    I'm a long time user of ISP, usually I figure out how to solve my issues (thanks to this forum most of time) but here I'm really stuck.

    The short story :
    - I installed a new server using the automated script (Ubuntu 20.04 / Nginx) and chosen to give a try to "rspamd" instead of the usual Amavis
    - Everything went well, so next I exported / imported the mailboxes from the old server to the new one using the ISP API/Script and a rsync of 'vmail'.
    - No issue with the migration, mailboxes are here BUT delivery does not work because of a "connect to 127.0.0.1[127.0.0.1]:10024: Connection refused" error.
    - BUT delivery works for new created mailboxes

    I started digging every where, what I've tried :
    - forced update of ISP with "reconfigure services? yes"
    - changed setting to Amavis, saved, then set it back to Rspamd and saved again, mailboxes where updated, but nothing changed
    - "grepped" entire /etc to find "10024", only find something in "postfix/tag_as_foreign.re", removed, restarted postfix/clamav, no luck
    - "grepped" the entire database to find "10024" but nothing
    - "grepped" inside an imported mailbox to find "10024" but nothing

    So the question is : where could be this filter for these imported mailboxes ?
    Does not seem to be in /etc, not in the DB and not in the mailbox itself... it's driving me crazy.

    Thanks for your suggestions :)

    EDIT:
    - in fact I've both "connect to 127.0.0.1[127.0.0.1]:10026: Connection refused)" and "127.0.0.1[127.0.0.1]:10024: Connection refused" errors
    - forgot to said that Rspamd is working well (for the new mailboxes)
    - and that I checked https://www.howtoforge.com/replacing-amavisd-with-rspamd-in-ispconfig/ but nothing is said about updating a setting in the existing mailboxes

    EDIT2:
    it was well the 2 filters setup in ./postfix/tag_as_originating.re and ./postfix/tag_as_foreign.re because by removing them new mails are well delivered

    so the questions are now:
    - why these filters were here?
    - how can I tell postfix to ignore these filters in the queue (as the mails seem "tagged" only here now)?
     
    Last edited: Mar 31, 2022
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    Is it possible that you copied over any config files from old server and not just mailbox contents?
     
  3. blackangel

    blackangel New Member

    Ok, so, the fix for this situation is well :
    - changed setting to Amavis, saved, then set it back to Rspamd and saved again
    this update the imported mailboxes

    BUT, mails already in queue will be stucked, so do a simple "postsuper -r ALL" and "postqueue -f" to force delivery of them, and voila :)
     
  4. blackangel

    blackangel New Member

    Thanks for the reply. But I don't think so, I only copied the content of 'vmail'.
    I really think the issue is the import that does not check the availability of amavis and import the raw settings of the mailboxes.
    So switching the config on the new server force the update of the old settings.
     
  5. till

    till Super Moderator Staff Member ISPConfig Developer

    If you used a tool from ISPConfig, then that's not the case as neither rspamd nor Amavis is involved in the import. if you used any third-party tool, then it might be.
     
  6. blackangel

    blackangel New Member

    Only used the tool "Import email configuration from ISPConfig 3" and done a rsync of /var/vmail as I often do.
    The only difference between this migration and the previous ones I did, the same way, is that I've chosen "Rspamd" instead of "Amavis" during the install of the new server.

    Now, switching from Rspamd, then Amavis and then Rspamd in the server config has clearly re-configured the imported mailboxes (on the last switch) as it was visible in the red pill after saving. Also, probably, removing the 2 files postfix/tag_as_originating.re and postfix/tag_as_foreign.re has helped.

    At first, I thought it didn't work because of mails in the queue with the "connection refuse" error but this was another thing in fact...

    Well, just sharing my feedback and experience on this case. Maybe it will help someone in the same situation one day :)

    In all cases, many thanks for this great tool that I used since more than 12 years now... wow, we are getting old ;)
     

Share This Page