Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


    Cloudron Forum

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular

    Solved Error CONNECT ECONNREFUSED wrong internal IP

    Support
    mail
    4
    12
    494
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      rfg last edited by girish

      Hi,

      I am getting this error when trying to send an email test from the admin page.

      connect ECONNREFUSED 172.18.0.7:2525

      However that's no the instance internal IP.

      I'm using an EC2 AWS with Elastic IP. On the Network page the Public IP is detected correctly, however I don't know from where is getting this internal IP.

      Thanks in advance

      girish 1 Reply Last reply Reply Quote 0
      • girish
        girish Staff @rfg last edited by girish

        @rfg So, from what I see in the logs, there are multiple issues:

        • There seems to be logs of bouncing happening. This is expected because EC2 does not allow mails to be sent out directly. You have to setup a relay - https://docs.cloudron.io/email/#relay-outbound-mails
        • The mail container is in debug mode. Not sure if this was intentional? If you go to Services -> Mail -> Edit. Remove the debug mode. When debug mode is enabled, the mail container is not even running.
        • There is also some crash in haraka (our mail server).

        Can you try this:

        • On the server, if you go to /home/yellowtent/boxdata/mail/haraka-queue . Do you see a lot files here? If so, these are the mails that failed to deliver and it's trying to deliver them forever (well, a very long time). You can just delete all the files inside that directory and then docker restart mail

        • Remove the debug mode that I mentioned above.

        • Send test mail. Does that work now? I think EC2 allows a very small amount of mails to be sent directly but I am not 100% sure about this. If you paste the logs when it tries to send the test mail, that will help. You can do this by opening the logs window in another browser tab and then clicking send test mail in another window.

        R 1 Reply Last reply Reply Quote 0
        • girish
          girish Staff @rfg last edited by girish

          @rfg this IP is in the internal docker network (docker inspect mail will give you the above IP address). If you go to Services view, is the mail service running ? If not, can you try restarting it and check sending mail afterwards?

          R 2 Replies Last reply Reply Quote 0
          • R
            rfg @girish last edited by

            @girish thanks, restarting the server fixed it. 🙂

            1 Reply Last reply Reply Quote 0
            • R
              rfg @girish last edited by rfg

              @girish It worked for a short time. Now is reporting same error.

              What could be wrong?

              Log:
              https://www.dropbox.com/s/f5uelj2dsl5pa4m/mail.zip?dl=0

              nebulon 1 Reply Last reply Reply Quote 0
              • nebulon
                nebulon Staff @rfg last edited by

                @rfg hm I can see the mail service crashing a few times and thus restarting, so maybe this happens too often and docker reassigns IPs. The error from the logs is:

                2022-02-17T12:33:00.000Z [INFO] [012E9F33-1E0E-4A1F-901A-C89B83E4FD2A.1794.1] [outbound] bouncing mail: 554 Failure g_imap_max_limit exceeded 199990/199990 folder new
                2022-02-17T12:33:00.000Z [ERROR] [012E9F33-1E0E-4A1F-901A-C89B83E4FD2A.1794.1] [outbound] Unrecognized response from upstream server: \r
                2022-02-17T12:33:00.000Z [INFO] [012E9F33-1E0E-4A1F-901A-C89B83E4FD2A.1794.1] [outbound] bouncing mail: Unrecognized response from upstream server: \r
                2022-02-17T12:33:00.000Z [CRIT] [-] [core] Error: We are already running hooks! Fatal error!
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at Object.plugins.run_hooks (/app/code/haraka/plugins.js:431:15)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at HMailItem._bounce (/app/code/haraka/outbound/hmail.js:1285:17)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at HMailItem.bounce (/app/code/haraka/outbound/hmail.js:1274:14)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at pluggableStream.<anonymous> (/app/code/haraka/outbound/hmail.js:699:22)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at pluggableStream.emit (events.js:315:20)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at pluggableStream.on_socket_data (/app/code/haraka/line_socket.js:25:20)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at pluggableStream.emit (events.js:315:20)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at TLSSocket.<anonymous> (/app/code/haraka/tls_socket.js:59:18)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at TLSSocket.emit (events.js:315:20)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at addChunk (internal/streams/readable.js:309:12)
                2022-02-17T12:33:00.000Z [NOTICE] [-] [core] Shutting down
                

                We have to investigate if this is something which requires a fix in haraka. Until that the previous temporary solution would have to be used 😕

                R 1 Reply Last reply Reply Quote 0
                • R
                  rfg @nebulon last edited by

                  @nebulon do you think upgrading to Ubuntu 18.04 would help?

                  nebulon 1 Reply Last reply Reply Quote 0
                  • nebulon
                    nebulon Staff @rfg last edited by

                    @rfg I don't think it will make a difference here, since all those services run in their own container, not directly on the host system. However if you are still on Ubuntu 16, then yes it is still time to upgrade first to 18 and then ideally to 20 already https://docs.cloudron.io/guides/upgrade-ubuntu-18/

                    R 1 Reply Last reply Reply Quote 1
                    • R
                      rfg @nebulon last edited by

                      @nebulon ok I'll try that. Also I noticed this error

                      554 Failure g_imap_max_limit exceeded 199990/199990 folder new
                      

                      It could be some big mailbox's folder?
                      Is there a way to inspect/delete/move the bigger ones?

                      girish 1 Reply Last reply Reply Quote 0
                      • girish
                        girish Staff @rfg last edited by girish

                        @rfg So, from what I see in the logs, there are multiple issues:

                        • There seems to be logs of bouncing happening. This is expected because EC2 does not allow mails to be sent out directly. You have to setup a relay - https://docs.cloudron.io/email/#relay-outbound-mails
                        • The mail container is in debug mode. Not sure if this was intentional? If you go to Services -> Mail -> Edit. Remove the debug mode. When debug mode is enabled, the mail container is not even running.
                        • There is also some crash in haraka (our mail server).

                        Can you try this:

                        • On the server, if you go to /home/yellowtent/boxdata/mail/haraka-queue . Do you see a lot files here? If so, these are the mails that failed to deliver and it's trying to deliver them forever (well, a very long time). You can just delete all the files inside that directory and then docker restart mail

                        • Remove the debug mode that I mentioned above.

                        • Send test mail. Does that work now? I think EC2 allows a very small amount of mails to be sent directly but I am not 100% sure about this. If you paste the logs when it tries to send the test mail, that will help. You can do this by opening the logs window in another browser tab and then clicking send test mail in another window.

                        R 1 Reply Last reply Reply Quote 0
                        • R
                          rfg @girish last edited by

                          @girish that was it!!!

                          After deleting a bunch of files in that path everything is working fine now.

                          Yes, I enabled the email debug mode.

                          Many, many thanks, I really appreciate your support.

                          scooke 1 Reply Last reply Reply Quote 0
                          • scooke
                            scooke @rfg last edited by

                            @rfg What was IT? Which of the suggestions was the solution?

                            A life lived in fear is a life half-lived

                            R 1 Reply Last reply Reply Quote 1
                            • R
                              rfg @scooke last edited by

                              @scooke Solution was deleting a buch of files from path:

                              /home/yellowtent/boxdata/mail/haraka-queue
                              

                              that files were created past Jan-06.

                              On that day we had an account hijacked that started sending out spam. I deactivated the account and it was working fine until past feb-16th, when email service started to crash.

                              HTH.

                              1 Reply Last reply Reply Quote 1
                              • First post
                                Last post
                              Powered by NodeBB