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



  • Hi,
    is there anybody to reply while fbartels is on leave?

    Still my problem is, that I cannot get Kopano working to receive eMails.
    Fetchmail seems not capable to deliver to virtual Mailboxes.
    Kopano on the other hand seems not to work as zarafa used to (with system users).
    So, what is the recommended way from Kopano? How can inbound Mails be received?

    In the Manual, I always find documentation about OUTbound mail (via postfix + dagent + spooler) but I have not seen any hint about INcoming mails.

    Can anybody help?



  • You’re configuring virtual domains, but setting up mailbox_transport.
    virtual_mailbox_transportmight be your intention.

    Useful information on Postfix virtual domains: VIRTUAL_README

    Is the kopano-user configured with both email-adresses of heinrich (heinrichxxxx@xxxxxx.de and heinrichxxxx@gmx.de)?

    ++umgfoin.

    .



  • Hello, umgfoin,

    thanks for replying.

    You are right, I am mixing this up and this reflects my situation - in Zarafa, I never had to deal with virtual users.
    So, am I right, that fetchmail is unable to handle delivery to virtual boxes?

    Users: I have 2 users: ‘heinrich’ is one, ‘gmx’ the other. Each of them has only one eMail address.

    Does this inspire you for more ideas? ;-)

    Thanks!

    Heinrich



  • Hello,

    has anybody more hints for me?

    Current status:
    Outbound Mail works.
    Inbound mail to gmx works - because I use an alias file.
    Surprisingly, this does not work for the other user.
    Postfix returns a “mail loop” notification - despite the fact, that I do absolutely the same like for the gmx user.
    So, is Kopano limited to 1 user only?

    How do you guys deal with inbound mails?
    Any other suggestions besides Fetchmail?

    I always read descriptions for outgoing mail - but what is a working solution for inbound mail ??

    Thanks!

    Heinrich



  • Hello,
    I hope, I can help. Why do you forward incoming mails from fetchmail to postfix? I think it is more elegant to send them directly to the kopano-dagent. I do this on some setups as well.

    Please give it a try with this fetchmail configuration:

    poll example.com with proto POP3
            user "heinrich@****.de" password "****"
            options ssl sslcertck
            mda "/usr/sbin/kopano-dagent heinrich"
    
    poll pop.gmx.net with proto POP3
            user "*****@gmx.de" password "****"
            options ssl sslcertck
            mda "/usr/sbin/kopano-dagent gmx"
    

    Please also check whether your kopano-dagent is enabled. On Debian/Ubuntu it is one line in /etc/default/kopano:
    DAGENT_ENABLED=yes

    After that you can optinally use transport maps for outgoing mails. When sending mails to local users it is more elegant to not send them out to your smarthost and fetch them with fetchmail. Just create a postfix lookup file like this. If the recipient is a kopano user, postfix delivers the mail directly to the kopano-dagent instead of sending the mail to your smarthost.

    /etc/postfix/transport.mysql:

    user = dbuser
    password = dbpass
    hosts = 127.0.0.1:3306
    dbname = kopano
    query = select 'lmtp:localhost:2003' from objectproperty where objectid=(select objectid from objectproperty where value='%s' limit 1) and propname='loginname';
    

    Enable this file in your main.cf:

    transport_maps = mysql:/etc/postfix/transport.mysql
    

    I hope it helps and I would be happy to know if it has worked.

    best regards,
    Rob



  • Hello, Rob,

    thanks for your idea. Unfortunately, this doesn’t work either.
    I reconfigured my fetchmailrc like you suggested, but then just nothing happened, no log entry in the mail.log.
    However, dagent.log returned the following:

    Unable to open logfile '/var/log/kopano/dagent.log' as user 'kopano'
    Not enough permissions to append logfile '/var/log/kopano/dagent.log'. Reverting to stderr.
    Sat May 27 23:21:52 2017: [31652] [error  ]   Python type: (null)
    Sat May 27 23:21:52 2017: [31652] [error  ]   Python error: 'module' object has no attribute 'DAgentPluginmanager'
    Sat May 27 23:21:52 2017: [31652] [crit   ] K-1732: Unable to initialize the dagent plugin manager: Unknown error code (1).
    

    So, obviously, the plugin doesn’t work.

    Is this a general Kopano issue (as I saw some tread about this somewhere here in the Forum) ?

    In General, the dagent was already set to “yes”, so that was working before.

    Once I have the inbound mails working, I might try the transport maps as you suggested …

    Any other idea for inbound mail delivery please? Which other options do you know besides fetchmail?

    Thank you so much for taking care!

    Heinrich



  • OK, I followed that tread: link text and disabled the plugin manager. Now I receive Mails on both accounts! WOOW ! ;-) Do you think this is a sustainable solution? What else will not work, while the plugin Manager is disabled? Also do you have an idea, why the log says Unable to open logfile '/var/log/kopano/dagent.log' as user 'kopano' – when I issue an ls -la, then I see ```
    ls -la /var/log/kopano/dagent.log
    -rw-r–r-- 1 kopano kopano 78642 Mai 27 23:54 /var/log/kopano/dagent.log



  • Hmm I am afraid I was happy TOO early … now everything is slow, from the “heinrich” account I hardly can do anything - not even contacts can be resolved.
    :-( :-( :-(



  • 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.



  • 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


  • 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



  • 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



  • 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



  • You can close this thread

    I give up. Will try Kolab Server now.



  • 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.



  • 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 …


Log in to reply
 

Looks like your connection to Kopano Community Forum was lost, please wait while we try to reconnect.