[SOLVED] Receiving mail from MultiPOP3 Server

[javamon]

5.0.0 GA open source on Ubuntu 6.06lts:

Is multipop still a command line only configuration option? I don't see anything in the UI - the "external account option" seems to have the same functionality as earlier (4.5.x) releases - i.e.: it will only poll the external pop when logged into the web client and "get mail" is selected.

Thanks. (upgrade process went smoothly, for what it's worth)

[jholder]

Yes, only from the command line.

[Alias Node]

Thanks, the above hint works swell!

But it exposes another problem: the passwords keep disappearing from my external account settings? (Zimbra 5.0 Open Source Edition)

Is anyone else seeing this? Is there a cure?

[CrypTom]

Originally Posted by gmbyron

Okay, here is a solution for all of you. I don't know why exactly it worked that way but it worked.. Apparently default COS won't apply to existing accounts so I had to change it on account basis

zimbra@mail$ zmprov
prov> mds [username (email without domain)] [data source/ext. pop account name] zimbraDataSourcePollingInterval 60

repeat mds for every account and data source.

Thanks for pointing out how to configure it correctly for existing external accounts. But it can't be the necessary procedure for new external accounts. Newly created external accounts should inherit the value specified in the COS instead of just setting the zimbraDataSourcePollingInterval to 0 (which - I guess - means "never").

I set the zimbraDataSourcePollingInterval for the entire COS to 180 and created a new external account. The zimbraDataSourcePollingInterval for this newly created data source is set to 0, why?

I want our users to be able to add external accounts without interaction with me. I don't want to manually set the polling interval an each and every external account... Am I getting something wrong?

[phoenix]

Originally Posted by CrypTom

I want our users to be able to add external accounts without interaction with me. I don't want to manually set the polling interval an each and every external account... Am I getting something wrong?

New users do inherit the COS when they're created. Run the following and post the output:

zmprov gc yourCOS | grep Polling

create a new user without any external mailbox then run this:

zmprov ga newaccount@yourdomain.com | grep Polling

Let's see if it's picked up the COS settings.

The data source polling interval is set to zero because each source being polled can override the COS polling interval. You should find entries in the logs indicating that Zimbra is polling the external accounts, are there any entries?

[CrypTom]

Originally Posted by phoenix

New users do inherit the COS when they're created. Run the following and post the output:

zmprov gc yourCOS | grep Polling

zimbraDataSourceMinPollingInterval: 1m
zimbraDataSourcePollingInterval: 600
zimbraFeatureMailPollingIntervalPreferenceEnabled: TRUE
zimbraMailMinPollingInterval: 2m
zimbraPrefMailPollingInterval: 5m

Originally Posted by phoenix

create a new user without any external mailbox then run this:

zmprov ga newaccount@yourdomain.com | grep Polling

Let's see if it's picked up the COS settings.

zimbraDataSourceMinPollingInterval: 1m
zimbraDataSourcePollingInterval: 600
zimbraFeatureMailPollingIntervalPreferenceEnabled: TRUE
zimbraMailMinPollingInterval: 2m
zimbraPrefMailPollingInterval: 5m

I did _not_ create a new user, but posted the output of an existing user that has never touched external accounts yet. The manually set Interval (600) has been inherited. When I run the command with my account (where I have manually set the account's polling interval before changing the COS) I get 180 instead of 600.

Creating new users (= replacing the existing users) is not an option as our server is productive...

Originally Posted by phoenix

The data source polling interval is set to zero because each source being polled can override the COS polling interval. You should find entries in the logs indicating that Zimbra is polling the external accounts, are there any entries?

Ahh, so 0 does not mean "never" but "inherit". Which is strange because I personally have to external accounts configured (after setting the COS poll interval). One external account is receiving mails (but only after changing the ds poll interval manually), the other (still 0) does not receive mails automatically.

As to the logs:
I only find entries like the one below

[ScheduledTask-9] [name=user@mydomain.ch;mid=328;ds=gmx;] datasource - Import completed.

Entries with the Keyword "ScheduledTask" only exist for data sources where I have manually set the poll interval.

[phoenix]

Originally Posted by CrypTom

Ahh, so 0 does not mean "never" but "inherit". Which is strange because I personally have to external accounts configured (after setting the COS poll interval). One external account is receiving mails (but only after changing the ds poll interval manually), the other (still 0) does not receive mails automatically.

I have to apologise for my answer to this, it seems I was looking at the wrong information this morning. The current setting is zero and that does mean 'never poll', you need to set it manually for the moment, there's an outstanding RFE to expose this feature in the UI. Add your vote and comments to that RFE.

To modify the polling via cli you need to do the following:

zmprov mds account@yourdomain.com datasourcename zimbraDataSourcePollingInterval 5m

and that does work.

My apologies again for that mistake.

[mmorse]

Keep in mind the data-source name isn't going to be the same for every account, but do the rest of the values inherit from COS properly if you null them out?

Originally Posted by mmorse

su - zimbra
zmprov mds user@domain.com [Data source external IMAP/POP account name] zimbraDataSourcePollingInterval 900s

zimbraDataSourceMinPollingInterval is usually 60s or 1m or 2m & zimbraFeatureMailPollingIntervalPreferenceEnabled should be set to TRUE

To cancel polling, set the mds attribute value to an empty string ('') or 0. Keep in mind that zimbraDataSourceMinPollingInterval gets inherited from the COS to the account to the data source. If a child object sets the value to "", it inherits the parent's value - if set to 0, it's turned off.

To expose that for the end user vote for: Bug 22114 - Expose external account polling interval in UI

[CrypTom]

Originally Posted by mmorse

Keep in mind the data-source name isn't going to be the same for every account, [...]

Thats exactly the reason why I'm writing here. It's not very efficient having to write a script that (periodically, because users could add new external accounts anytime!) processes every user, parses its data sources and sets the polling time, compared to the possibility to just inherit the COS value by default!

Originally Posted by mmorse

[...] but do the rest of the values inherit from COS properly if you null them out?

What do you mean by "the rest of the values". I don't see other data source values which could be inherited:

zmprov gds user@mydomain.ch
objectClass: zimbraDataSource
objectClass: zimbraPop3DataSource
zimbraDataSourceConnectionType: ssl
zimbraDataSourceEmailAddress: xxxxxxxxxx
zimbraDataSourceEnabled: TRUE
zimbraDataSourceFolderId: 81179
zimbraDataSourceHost: xxxxxxxxxx
zimbraDataSourceId: cb9aaa47-afbd-49eb-aa5b-829af505453e
zimbraDataSourceLeaveOnServer: TRUE
zimbraDataSourceName: xxxxxxxxxx
zimbraDataSourcePollingInterval: 0
zimbraDataSourcePort: 995
zimbraDataSourceUsername: xxxxxxxxxx
zimbraPrefFromAddress: xxxxxxxxxx
zimbraPrefFromDisplay: xxxxxxxxxx

Thanks
Tom

[scohol]

I have this setup, and it works great except every now and again polling to an external POP3 server times out.

This causes the datasource to stop polling until the POP3 account is reconfigured in the Webclient.

What i was wondering is, wouldn't it be nice to have a feature to retry even though it failed. And then after a certain number of failed attempts it should deactivate the external POP3 account. Not after one failure.

Because this goes unnoticed for people that don't use the webclient as they don't get the prompt telling them there is something wrong with the external POP3 account.