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

I need to add, that when I run “mutt” from the shell, I find the mails that fetchmail has pulled from the server. Bingo!

The Mail store for Mutt is /var/mail/heinrich

How can I make it to deliver them to the Kopano Web App?

How can get my Mails into WebApp instead of mutt?

There is only 1 user “heinrich” on the system - so why is the eMail delivered to mutt, but not to copano?
Also the kopano user “heinrich” has the same password like the system user “heinrich” - so I would expect that the delivery should work properly.

Any other suggestions?

fbartels

Kopano

Is it really heinrich@localhost? It seems that you lookups in virtual_alias_maps and virtual_mailbox_maps are not successful, and therefore he defaults back to local delivery.

Hi All,
I have tried now literally ANY how-to, but never succeed.
The original Kopano documentation may be good, but it confuses me with all of the different options(DB-plugin,LDAP, virtual), but I have not seen a complete main.cf.
@Felix, I guess you are right, that it might be somehow related to my bad local user lookup - anyway, I changed this also to the mysql version (mysql:/etc/postfix/mysql-users.cf), but also this doesn’t work.
Is there a chance that someone uploads a working main.cf with basic functionality?

fbartels

@hoinz_p you are using users in MySQL?

Hi Felix,
yes that is the setup as described in the Kopano Documentation:

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
virtual_alias_maps = mysql:/etc/postfix/mysql-users.cf

Where “mysql-users.cf” contains an Mysql request:

user = kopano
password = *****
hosts = 127.0.0.1
dbname = kopano
query = select value from objectproperty where \
        objectid=(select objectid from objectproperty where value='%s' limit 1) \
        and propname='loginname';

That was just one more attempt of configuration.
You said its the same like Zarafa - definitively NOT :-) In Zarafa I worked with “real” users as they exist on my Ubuntu system.
Here it seems that its no longer possible(only LDAP, AD,Mysql or Virtual).
As I don’t want to run into more problems, I don’t try LDAP and AD, but just tried the 2 things: Virtual Users and MySQL.

In the meantime (I did more testing yesterday night) I managed to send and receive mails within the Mail application “mutt”. When I had Zarafa, the incoming Mails were visible in Mutt and Zarafa Webaccess in parallel.
This is also different here. I see the mails in Mutt, but I do not see them in Kopano WebApp.
The WebApp seems to work in General(as I get “not delivered” replies), but it seems to have the mails stored in a different location.
Can you tell me, how to influence it?
Can I tell Postfix, where to store the Mails?

Thanks for your time!

Hoinz

fbartels

Hello @hoinz_p ,

I still have to find the time to write a more verbose reply, but already wanted to comment on the following.

@hoinz_p said in Kopano Dagent does not deliver incoming Mails // Outbound mails OK:

You said its the same like Zarafa - definitively NOT :-) In Zarafa I worked with “real” users as they exist on my Ubuntu system.
Here it seems that its no longer possible(only LDAP, AD,Mysql or Virtual).

the unix backend, while surely not actively tested for a while, is still part of the codebase and can be used. https://stash.kopano.io/projects/KC/repos/kopanocore/browse/installer/linux/server.cfg#335-338

Dear Felix,
still urgently need your support.

Progress so far: I found a mistake in my relaymap, so that the delivery agent did not even kick in.
This is now solved, I see the delivery agent working.
However, still the Mails are not delivered into the mailbox.

I have 2 users, ‘heinrich’ and ‘gmx’

My fetchmail config says

poll xxxxxxx.de protocol pop3 interval 1 user "heinrichxxxx@xxxxxxx.de" password "xxxxxxx" is heinrich here ssl

poll pop.gmx.net protocol pop3 interval 1 user "heinrichxxxx@gmx.de" password "xxxxxxxxx" is gmx here ssl

The above config works in first instance, however, the delivery agent does not resolve “heinrich” or “gmx” correctly. Normally he should just deliver to the system users ‘heinrich’ and ‘gmx’. But it doesnt:

Thu May  4 22:42:01 2017: [debug  ] [ 7800] < 250-SERVER ready
Thu May  4 22:42:01 2017: [debug  ] [ 7800] < 250-PIPELINING
Thu May  4 22:42:01 2017: [debug  ] [ 7800] < 250-ENHANCEDSTATUSCODE
Thu May  4 22:42:01 2017: [debug  ] [ 7800] < 250 RSET
Thu May  4 22:42:01 2017: [debug  ] [ 7800] > MAIL FROM:<heinrichxxxx@gmx.de>
Thu May  4 22:42:01 2017: [debug  ] [ 7800] < 250 2.1.0 Ok
Thu May  4 22:42:01 2017: [debug  ] [ 7800] > RCPT TO:<heinrich@localhost>
Thu May  4 22:42:01 2017: [debug  ] [ 7800] Resolved command "RCPT TO:<heinrich@localhost>" to recipient address "heinrich@localhost"
Thu May  4 22:42:01 2017: [error  ] [ 7800] Failed to resolve recipient heinrich@localhost (0)
Thu May  4 22:42:01 2017: [error  ] [ 7800] Requested e-mail address 'heinrich@localhost' does not resolve to a user.

So, any idea, where does the @localhost come from ???

My latest main.cf is

mydomain = xxxx-hub.local
mydestination = xxxx-hub.local, localhost

smtpd_banner = $myhostname ESMTP
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = /usr/share/doc/postfix

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtp_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
myhostname = plett-hub
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
virtual_alias_domains = xxxxxx.de, gmx.de
virtual_alias_maps = hash:/etc/postfix/virtual
mailbox_transport = lmtp:localhost:2003
mynetworks = 192.168.2.0/24 10.124.205.0/24 10.88.36.0/24 10.88.37.0/24 127.0.0.0/8 [::1]/128
mailbox_size_limit = 51200000
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
#Outbound Relay
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
sender_dependent_relayhost_maps =hash:/etc/postfix/relaymap
smtp_sender_dependent_authentication = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/passes
smtp_sasl_security_options = noanonymous

And the Virtual alias file is

heinrichxxxx@xxxxxx.de              heinrichxxxx@xxxxxx.de ### so, just the real eMail addresses
heinrichxxxx@gmx.de          heinrichxxxx@gmx.de

Thanks!

Heinrich

Oops, just realized, Felix seems to be on holiday …:boy_tone2:
Anybody else out there with an idea, please?

The Question is, why my ‘username’ gets translated into ‘username@localhost’, despite I have not configured this?
And WHICH application is responsible? Fetchmail? Postfix? Kopano? See also the post above.

Thanks!

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?

umgfoin

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

robgnu

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.
:-( :-( :-(

robgnu

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:

Try to “repair” your permissions (again?):

chown -R kopano:kopano /etc/kopano/
chown -R kopano:kopano /var/log/kopano/

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: