Navigation

    Kopano
    • Register
    • Login
    • Search
    • Categories
    • Get Official Kopano Support
    • Recent
    Statement regarding the closure of the Kopano community forum and the end of the community edition

    Kopano Dagent does not deliver incoming Mails // Outbound mails OK

    Kopano Groupware Core
    5
    29
    12720
    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.
    • robgnu
      robgnu last edited by

      Hello, Heinrich,

      it is correct, that there are no entrys in mail.log when using my approach. The reason is that you bypass postfix . But if you watch the fetchmail logs with this command journalctl -f -u fetchmail.service you can see what happens with your incoming mails.

      I think the problem could be in your dagent.cfg. Please post your dagent.cfg here with this command: cat /etc/kopano/dagent.cfg | egrep -v "(^#.*|^$)" (This command removes the comments.)

      This is the dagent.cfg on my machines (kopano-dagent v. 8.4.0~125):

      root@mailserver:~# cat /etc/kopano/dagent.cfg | egrep -v "(^#.*|^$)"
      log_method      =       file
      log_file = /var/log/kopano/dagent.log
      log_timestamp   =       1
      log_raw_message = no
      log_raw_message_path = /tmp
      tmp_path = /tmp
      lmtp_port = 2003
      lmtp_max_threads = 20
      coredump_enabled = no
      spam_header_name = X-Spam-Status
      spam_header_value = Yes,
      archive_on_delivery = no
      plugin_enabled = yes
      plugin_manager_path = /usr/share/kopano-dagent/python
      plugin_path = /var/lib/kopano/dagent/plugins
      set_rule_headers = yes
      no_double_forward = no
      

      Please also check these points:

      1. Try to “repair” your permissions (again?):
      chown -R kopano:kopano /etc/kopano/
      chown -R kopano:kopano /var/log/kopano/
      
      1. Check your /etc/kopano/server.cfg (You need the fetchmail user on the local_admin_users, when using my approach):
      local_admin_users       = root kopano fetchmail
      

      What happens when you increase your debug_level?

      Best regards,
      Rob.

      1 Reply Last reply Reply Quote 0
      • A Former User
        A Former User last edited by

        Hello, Rob,

        thanks again for your help.

        Here is the config of my dagent:

        root@plett-hub:~# glances
        root@plett-hub:~# cat /etc/kopano/dagent.cfg | egrep -v "(^#.*|^$)"
        log_method      =       file
        log_level       =       6
        log_file = /var/log/kopano/dagent.log
        log_timestamp   =       1
        log_raw_message = no
        log_raw_message_path = /tmp
        tmp_path = /tmp
        server_bind =
        lmtp_port = 2003
        lmtp_max_threads = 20
        coredump_enabled = no
        spam_header_value = No
        archive_on_delivery = no
        plugin_enabled = yes
        plugin_manager_path = /usr/share/kopano-dagent/python
        plugin_path = /var/lib/kopano/dagent/plugins
        set_rule_headers = yes
        no_double_forward = no```
        
        I have set the permissions as you suggested and also "fetchmail" was already member of the "local_admin_users".
        
        The weird thing now is: I can send 1 eMail out successfully.
        
        When I open another Mail and click on "send", there is no response from the Kopano WebApp.
        The CPU load increases to 1.4 and the top process is "mysqld".
        And this is with fetchmail disabled!
        
        ![0_1496251246321_Kopano_Process_Mysql.PNG](/assets/uploads/files/1496251120231-kopano_process_mysql-resized.png) 
        
        I fear I cannot go for Kopano anylonger... it just takes time and seems not a operational system. I think I have really tried a lot ... I still wonder, which tool all the other users take for inbound mails. Obviously, the minority is working with Fetchmail!
        
        Any final ideas?
        
        Thanks!
        
        Heinrich
        1 Reply Last reply Reply Quote 0
        • A Former User
          A Former User last edited by

          Oops I put it all into the wrong window … here is the Process view of my CPU while Kopano is struggling:

          0_1496251326691_Kopano_Process_Mysql.PNG

          1 Reply Last reply Reply Quote 0
          • A Former User
            A Former User last edited by

            I fear I cannot go for Kopano anylonger… it just takes time and seems not a operational system. I think I have really tried a lot … I still wonder, which tool all the other users take for inbound mails. Obviously, the minority is working with Fetchmail!

            Any final ideas?

            Thanks!

            Heinrich

            1 Reply Last reply Reply Quote 0
            • A Former User
              A Former User last edited by

              In the /var/log/kopano/server.log, I find the following errors:

              Wed May 31 21:44:34 2017: [error  ] K-1570: type: entryid has size 22; not enough for EID_V0.usType (26)
              Wed May 31 21:44:34 2017: [error  ] eid.type(): K-1570: entryid is not of type EID_V0
              
              Wed May 31 21:45:26 2017: [error  ] K-1570: type: entryid has size 22; not enough for EID_V0.usType (26)
              Wed May 31 21:45:26 2017: [error  ] eid.type(): K-1570: entryid is not of type EID_V0
              
              Wed May 31 21:45:26 2017: [error  ] K-1570: type: entryid has size 22; not enough for EID_V0.usType (26)
              Wed May 31 21:45:26 2017: [error  ] eid.type(): K-1570: entryid is not of type EID_V0
              
              

              I thought this issue had been solved since 8.4.0.235 ?

              I am running

              apt list kopano-server
              Auflistung... Fertig
              kopano-server/now 8.4.0~324-67.1 amd64  [Installiert,lokal]
              root@plett-hub:~#
              

              … so would expect the issue is solved?

              Any other suggestions?

              Thanks!

              Heinrich

              1 Reply Last reply Reply Quote 0
              • A Former User
                A Former User last edited by

                You can close this thread

                I give up. Will try Kolab Server now.

                1 Reply Last reply Reply Quote 0
                • robgnu
                  robgnu last edited by

                  Hello,
                  sorry for my late response. If you still want to give Kopano a try, just write me an PM. If you want, I will try to help you by phone and/or with a Teamviewer-Session.

                  Rob.

                  1 Reply Last reply Reply Quote 0
                  • A Former User
                    A Former User last edited by

                    TO BE CLOSED I turned back to where i used to be, and “upgraded” to Ubuntu 14.04(I used to have 12.04 before the crash). Zarafa 7.1.11-46050 is still working fine, now the mails get delivered in and out, Fetchmail can again deliver to my local users and that is it.
                    I know that latest in 04/2019 I will have to take care to upgrade to something higher than Ub14.04, but then other parameters in my life may change aswell ;-)
                    Thanks to the community for your support anyway, even if I cannot call Kopano a “success story” for me. Bye, Heinrich <br>BTW, I tried Kollab Server, which didn’t work for me either …

                    1 Reply Last reply Reply Quote 0
                    • kamikaze
                      kamikaze last edited by

                      Dear all,

                      I know, that the topic is old. But I’ve had a simular problem and the info from @robgnu with the /etc/postfix/transport.mysql solved my problem.

                      And if someone else has a simular problem as well, maybe this info can help.

                      First of all my system: I installed kopano on a debian-10. I also installed fetchmail. I created user with mailaddress from my internal domain name eg: user1@mydomain.local and user2@mydomain.local
                      and some user with external mailaddress eg: user3@mydomain.de and also user4@gmx.de

                      For the internal user it works but for the user with external mailaddress fetchmail couldn’t deliver mails.
                      I tried fetchmail with kopano-dagent and without but no success.
                      Then I tried the mentioned tipp with transport.mysql - and it works !
                      I have to enter the external mailaddress in my /etc/postfix/virtual - but then it works.
                      And for me, it works better than expected, then: if I send a mail from user1@mydomain.local to user4@gmx.de the mail stays intern.
                      That it what I wanted !

                      I just want to describe it, if it someone else can help.

                      Best regards

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post