[Dovecot] dbus support in dovecot?
Greetings;
I am trying to transition from ubu10.04.4 LTS to ubu12.04.2 LTS, but in the changeover I want to setup dovecot as a local only imap server so that I can read & respond to email from any of the other 4 or so machines on my local net.
To that end, and given that I have a well working setup right now, using fetchmail driving mailfilter as a pre-check, procmail as the MTA delivering to /var/spool/mail/me, with clamav and spamd in the mix to intercept and send to /dev/null the worst of the spam, or to a quarantine file if clamav triggers.
The current transfer mechanism is driven by a script that uses inotifywait to detect newly delivered mail in that directory, and which then sends kmail a dbus message to go get the mail.
Since I want to insert dovecot into this chain, does dovecot have a dbus port, and if so, what is the format of the command it expects?
Thanks all.
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 24 Jul 2013, Gene Heskett wrote:
I am trying to transition from ubu10.04.4 LTS to ubu12.04.2 LTS, but in the changeover I want to setup dovecot as a local only imap server so that I can read & respond to email from any of the other 4 or so machines on my local net.
To that end, and given that I have a well working setup right now, using fetchmail driving mailfilter as a pre-check, procmail as the MTA delivering to /var/spool/mail/me, with clamav and spamd in the mix to intercept and send to /dev/null the worst of the spam, or to a quarantine file if clamav triggers.
The current transfer mechanism is driven by a script that uses inotifywait to detect newly delivered mail in that directory, and which then sends kmail a dbus message to go get the mail.
Since I want to insert dovecot into this chain, does dovecot have a dbus port, and if so, what is the format of the command it expects?
Dovecot does not have no dbus support, as far as I know. If you only want to monitor one (or some minor number of mailboxes), you would setup kmail using IMAP, then tag this mailboxes to be monitored. Dovecot then uses that open connection to signal a newly arrived message.
Kind regards,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUfDNdl3r2wJMiz2NAQJP3ggAqiPfjSNJm+VVSirdnx3fhk2JVlu0EkgL GUFt2vEnrsoKnqnJbo9sygjH+qL81tFS+aqN1be7yLd03pz+gBNTBNil5iG3yht3 evFoFY8m8t59wIRL4D/knIHR74tsoPxctMTvr/SmnpnmfrOQ+JuMh/Ni9/by8v8k RfyGrv3nKD16E/A01TFNfrzsnkplG9uXyl9O37UWvkPIeD7kO1cv+qkne2IQrQrH /pUmdf0C9Ws8u0hayvqZlgG4rfp/azefyde8jaMQrvghYyDqov442CgHokbvQcqO 7Bp7jvL6+UnHftLmTIionCT2pRgQAfqf+lw03bjH+EUKb0MEBoIRzg== =lr21 -----END PGP SIGNATURE-----
On Thursday 25 July 2013 07:10:38 Steffen Kaiser did opine:
On Wed, 24 Jul 2013, Gene Heskett wrote:
I am trying to transition from ubu10.04.4 LTS to ubu12.04.2 LTS, but in the changeover I want to setup dovecot as a local only imap server so that I can read & respond to email from any of the other 4 or so machines on my local net.
To that end, and given that I have a well working setup right now, using fetchmail driving mailfilter as a pre-check, procmail as the MTA delivering to /var/spool/mail/me, with clamav and spamd in the mix to intercept and send to /dev/null the worst of the spam, or to a quarantine file if clamav triggers.
The current transfer mechanism is driven by a script that uses inotifywait to detect newly delivered mail in that directory, and which then sends kmail a dbus message to go get the mail.
Since I want to insert dovecot into this chain, does dovecot have a dbus port, and if so, what is the format of the command it expects?
Dovecot does not have no dbus support, as far as I know. If you only want to monitor one (or some minor number of mailboxes), you would setup kmail using IMAP, then tag this mailboxes to be monitored. Dovecot then uses that open connection to signal a newly arrived message.
Kind regards,
Might be a workable solution, if the 12.4.2 LTS supplied kmail would run.
Unforch it throws an error no one on the kde-pim or kde mailing lists has
ever seen, and exits when the failure advisory is closed. Fat lot of good
at troubleshooting the problem that is, and one, just one of several
reasons I want to switch to claws-mail. Not to mention that in order to
post to either of those two lists, I have to nuke my whole sig else its
held forever as potential spam.
So, can this become a request for this dbus support to be added to dovecot?
Or does it have its own mechanism that would cause a newly arrived message
to be sieved or pigeonholed such that an imap client see's it asap? I am
not fussy how the job gets done, as long as it does.
Alternatively, if dovecot could take over for the fetchmail procmail/spamd/clamav chain I've been using for years, then it would know when a new message has been 'pop'ed from one of the servers I scan with fetchmail now.
I printed and scanned the Steve Litt dovecot docs, but wasn't able to glean
that info from what I have. And apparently the wiki2 pages have not been
collated into a pdf for reference as I try to make it work. I may have
something fubared there now, as my main mail server, which uses portsentry,
and I am winding up in that machines hosts.deny file file every time I boot
to 12.4.2 LTS + kde. I have that drive mounted in this boot.
And I can't fix it once I'm blocked because my ip is blocked, so I'd have to ssh into one of the other machines at the tv station, and then ssh from that machine to the mail server. I don't keep those passwords on the wall, or use them that often.
So, where in the boot sequence is dovecot started? I can mv the link in /etc/init.d, but since its a link to upstart, is that sufficient? Try it I guess.
Thanks for reading this far.
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: http://coyoteden.dyndns-free.com:85/gene is up! My views http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml Everything might be different in the present if only one thing had been different in the past. A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 25 Jul 2013, Gene Heskett wrote:
Date: Thu, 25 Jul 2013 07:57:55 -0400 From: Gene Heskett gheskett@wdtv.com To: dovecot@dovecot.org Subject: Re: [Dovecot] dbus support in dovecot?
On Thursday 25 July 2013 07:10:38 Steffen Kaiser did opine:
On Wed, 24 Jul 2013, Gene Heskett wrote:
I am trying to transition from ubu10.04.4 LTS to ubu12.04.2 LTS, but in the changeover I want to setup dovecot as a local only imap server so that I can read & respond to email from any of the other 4 or so machines on my local net.
To that end, and given that I have a well working setup right now, using fetchmail driving mailfilter as a pre-check, procmail as the MTA delivering to /var/spool/mail/me, with clamav and spamd in the mix to intercept and send to /dev/null the worst of the spam, or to a quarantine file if clamav triggers.
The current transfer mechanism is driven by a script that uses inotifywait to detect newly delivered mail in that directory, and which then sends kmail a dbus message to go get the mail.
Since I want to insert dovecot into this chain, does dovecot have a dbus port, and if so, what is the format of the command it expects?
Dovecot does not have no dbus support, as far as I know. If you only want to monitor one (or some minor number of mailboxes), you would setup kmail using IMAP, then tag this mailboxes to be monitored. Dovecot then uses that open connection to signal a newly arrived message.
Kind regards,
Might be a workable solution, if the 12.4.2 LTS supplied kmail would run. Unforch it throws an error no one on the kde-pim or kde mailing lists has ever seen, and exits when the failure advisory is closed. Fat lot of good at troubleshooting the problem that is, and one, just one of several reasons I want to switch to claws-mail. Not to mention that in order to post to either of those two lists, I have to nuke my whole sig else its held forever as potential spam.
So, can this become a request for this dbus support to be added to dovecot? Or does it have its own mechanism that would cause a newly arrived message to be sieved or pigeonholed such that an imap client see's it asap? I am not fussy how the job gets done, as long as it does.
Alternatively, if dovecot could take over for the fetchmail procmail/spamd/clamav chain I've been using for years, then it would know when a new message has been 'pop'ed from one of the servers I scan with fetchmail now.
there might be a misunderstanding here, Dovecot is an IMAP and POP3 server. It ships tools that replicate messages from other Dovecot servers and in limits from other IMAP servers.
If you intend to POP other servers, copy their messages to one local host and view your messages "offline", I would keep fetchmail and Co. Or when it suits more, maybe imapsync. If you keep that chain any local mailer should be able to pick up the locally spooled messages. Maybe you could switch to Maildir as backend, in order to minimizes locking issues. Of course, you could serve that local mail spool with Dovecot to other IMAP or POP3 clients.
You also could fetchmail the remote hosts and inject them into a local Dovecot server via LMTP, you can then try to run clamav and spamd from Sieve and you have the other Sieve-capabilities as well.
I printed and scanned the Steve Litt dovecot docs, but wasn't able to glean that info from what I have. And apparently the wiki2 pages have not been collated into a pdf for reference as I try to make it work. I may have something fubared there now, as my main mail server, which uses portsentry, and I am winding up in that machines hosts.deny file file every time I boot to 12.4.2 LTS + kde. I have that drive mounted in this boot.
And I can't fix it once I'm blocked because my ip is blocked, so I'd have to ssh into one of the other machines at the tv station, and then ssh from that machine to the mail server. I don't keep those passwords on the wall, or use them that often.
So, where in the boot sequence is dovecot started? I can mv the link in /etc/init.d, but since its a link to upstart, is that sufficient? Try it I guess.
Thanks for reading this far.
Cheers, Gene
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUfEXv13r2wJMiz2NAQJBFQf/aXqeUlzDa7u74cfyNhtPNPGbzwKg9TCJ LhO56PmSHP9pTQncOYcdgeOAu5brNv/zPB6xBifOrpnfbjcLRRov+78GGnTszozv Zn3LMqGXbvdPrxqdMa25W5/Znm3Ndpvtb8kdhK2GwW6tQFrs5gfW82P/OdQX4FU1 xNdL34xNImj8j74q1w9wHZ8xTcQMTJCdQKJheQktR/ftyi+Eu1obq7OVt9EoIrWY bu5TBcTOPnuOOC9AQLCk1K70usoUSRoQADHfnkymwX9BLQaWnhPTT/XsB4r9bBWp hmxQDsWof8Qm3AYqJcn7FibO9tLKGW9AldBwB0gM40z3CI1qIEUSyw== =Hxz+ -----END PGP SIGNATURE-----
On Thursday 25 July 2013 08:38:33 Steffen Kaiser did opine:
there might be a misunderstanding here, Dovecot is an IMAP and POP3 server. It ships tools that replicate messages from other Dovecot servers and in limits from other IMAP servers.
If you intend to POP other servers, copy their messages to one local host and view your messages "offline", I would keep fetchmail and Co.
That is the gist of what I have in mind.
Dovecot can I assume, watch the mailfiles in /var/spool/mail?
My present method of using inotifywait wrapped in a bash script to tell
kmail to go get the new mail via a dbus message has worked well for years.
But with no previous experience with imap, I haven't a clue how new mail
arrival is handled in that sort of a setup.
Or when it suits more, maybe imapsync. If you keep that chain any local mailer should be able to pick up the locally spooled messages. Maybe you could switch to Maildir as backend, in order to minimizes locking issues. Of course, you could serve that local mail spool with Dovecot to other IMAP or POP3 clients.
Already "pigeonhole"d or "sieve"d into the usual folder format? Once I get the sorting filter rules re manufactured, that would be great!
You also could fetchmail the remote hosts and inject them into a local Dovecot server via LMTP, you can then try to run clamav and spamd from Sieve and you have the other Sieve-capabilities as well.
LTMP is a new acronym to me. Sorry. Synonymous to an MTA? Effectively replacing procmail with dovecot and sieve but still using spamd and clamav?
Are there any better tutorials than Steve Litt's?, which seem to be getting a tad dated now.
Thank you Steffen.
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: http://coyoteden.dyndns-free.com:85/gene is up! My views http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml fortune: cpu time/usefulness ratio too high -- core dumped. A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens.
At 9AM -0400 on 25/07/13 you (Gene Heskett) wrote:
On Thursday 25 July 2013 08:38:33 Steffen Kaiser did opine:
there might be a misunderstanding here, Dovecot is an IMAP and POP3 server. It ships tools that replicate messages from other Dovecot servers and in limits from other IMAP servers.
If you intend to POP other servers, copy their messages to one local host and view your messages "offline", I would keep fetchmail and Co.
That is the gist of what I have in mind.
Dovecot can I assume, watch the mailfiles in /var/spool/mail?
My present method of using inotifywait wrapped in a bash script to tell kmail to go get the new mail via a dbus message has worked well for years.
But with no previous experience with imap, I haven't a clue how new mail arrival is handled in that sort of a setup.
If a mail client (kmail or anything else which supports IDLE) has a logged-in IMAP session which is sitting in IDLE, Dovecot will watch that user's mailspool and notify the client when new mail arrives.
What it won't do, however, is try to take that new mail out of the spool, filter it, and put it back. If you want Dovecot to filter mail you have to insert it into the delivery chain, before the mail gets to /var/spool/mail. There are two ways of doing this: with dovecot-lda, or with LMTP.
Or when it suits more, maybe imapsync. If you keep that chain any local mailer should be able to pick up the locally spooled messages. Maybe you could switch to Maildir as backend, in order to minimizes locking issues. Of course, you could serve that local mail spool with Dovecot to other IMAP or POP3 clients.
Already "pigeonhole"d or "sieve"d into the usual folder format? Once I get the sorting filter rules re manufactured, that would be great!
It sounds to me like you *just* want dovecot-lda. dovecot-lda is an MDA, that is, a program which does the same job as procmail or maildrop, and it supports Sieve. It also supports sieve extensions which let you run arbitrary programs, so you can run the mail through clamav/whatever.
If you configure Dovecot to keep mail in /var/spool/mail, and to use sieve, and then replace your current call to procmail with an equivalent call to dovecot-lda, I believe this will do what you want. I'm not sure, but I think with Dovecot 2 you will need to run the basic Dovecot daemons in order to make things work, but you can turn off IMAP and POP.
Of course, once you've got delivery working you could then turn IMAP back on, and get rid of that inotifywait hack. At that point there's no good reason to stick to an mbox format mailspool, since the only program which ever touches it is Dovecot, so you can switch to Maildir or dbox instead. However, I would strongly recommend changing only one thing at a time, and making sure the new setup works properly before changing anything else.
You also could fetchmail the remote hosts and inject them into a local Dovecot server via LMTP, you can then try to run clamav and spamd from Sieve and you have the other Sieve-capabilities as well.
LTMP is a new acronym to me. Sorry. Synonymous to an MTA? Effectively replacing procmail with dovecot and sieve but still using spamd and clamav?
You mean MDA. An MTA (Mail Transfer Agent) receives mail by SMTP and either hands it to an MDA or sends it out again by SMTP; an MDA takes mail from an MTA and does local delivery.
LMTP is a protocol for MTAs to talk to MDAs; that is, instead of the MTA invoking the MDA with command-line arguments and passing the message on stdin, it opens a socket (usually Unix-domain) and talks to the MDA on the other end. (The protocol itself is very nearly the same as SMTP, with one rather important difference.)
Using LMTP rather than a command-line MDA means the MDA runs as a daemon, and the MTA has to be configured to use an LMTP client rather than a command for delivery. As far as Dovecot is concerned this is pretty-much the only important difference.
Ben
On 7/25/2013 8:02 AM, Gene Heskett wrote:
On Thursday 25 July 2013 08:38:33 Steffen Kaiser did opine:
there might be a misunderstanding here, Dovecot is an IMAP and POP3 server. It ships tools that replicate messages from other Dovecot servers and in limits from other IMAP servers.
If you intend to POP other servers, copy their messages to one local host and view your messages "offline", I would keep fetchmail and Co.
That is the gist of what I have in mind.
Dovecot can I assume, watch the mailfiles in /var/spool/mail?
It can be configured to do so. Or it can be configured to directly receive the mail via pipe from Postfix using LDA or LMTP, and then write it to /var/spool/mail in mbox format, or to user maildirs.
My present method of using inotifywait wrapped in a bash script to tell kmail to go get the new mail via a dbus message has worked well for years.
But with no previous experience with imap, I haven't a clue how new mail arrival is handled in that sort of a setup.
Instant notification is built into IMAP4 w/the IDLE command. See: http://en.wikipedia.org/wiki/IMAP_IDLE
Or when it suits more, maybe imapsync. If you keep that chain any local mailer should be able to pick up the locally spooled messages. Maybe you could switch to Maildir as backend, in order to minimizes locking issues. Of course, you could serve that local mail spool with Dovecot to other IMAP or POP3 clients.
Already "pigeonhole"d or "sieve"d into the usual folder format? Once I get the sorting filter rules re manufactured, that would be great!
Not sure what you mean by "the usual folder format". Sieve will sort into your IMAP folders. These may or may not have a 1:1 correlation to filesystem folders. Depends on the mailbox storage format you choose.
You also could fetchmail the remote hosts and inject them into a local Dovecot server via LMTP, you can then try to run clamav and spamd from Sieve and you have the other Sieve-capabilities as well.
LTMP is a new acronym to me. Sorry. Synonymous to an MTA? Effectively replacing procmail with dovecot and sieve but still using spamd and clamav?
LMTP, Local Mail Transport protocol, is a subset of SMTP. It can be used locally or over the wire. With the Dovecot LMTP implementation, Sieve takes action on messages when they arrive, and Dovecot's indexes are updated appropriately as well. I'm not sure about spamd and clamav integration here. The vast majority of people using Dovecot deliver the mail via Postfix with LDA or LMTP, and do their AS/AV filtering in Postfix, where SPamassassin and clamav are but two of many possible packages. Many people run both of these via amavisd-new.
Are there any better tutorials than Steve Litt's?, which seem to be getting a tad dated now.
I'm not familiar with these tutorials.
What I would suggest Gene, if possible, is using the 'standard' Postfit/Dovecot config, doing AS/AV in Postfix, have an upstream system gather the mail from your various POP mailboxes and deliver them to an address hosted by Postfix via SMTP. In other words, push all of the non standard IMAP server methodology away from, upstream of, your Dovecot installation. I'd think one of the mailbox collation services could do this. I.e. POP a dozen mailboxes and forward all the mail to a single SMTP address. Maybe fetchmail can do this. I've never used it.
You may want to ask about this as OT on SDLU. Hundreds of years of combined mail experience there.
-- Stan
On Thursday 25 July 2013 15:13:58 Stan Hoeppner did opine:
On 7/25/2013 8:02 AM, Gene Heskett wrote:
On Thursday 25 July 2013 08:38:33 Steffen Kaiser did opine:
there might be a misunderstanding here, Dovecot is an IMAP and POP3 server. It ships tools that replicate messages from other Dovecot servers and in limits from other IMAP servers.
If you intend to POP other servers, copy their messages to one local host and view your messages "offline", I would keep fetchmail and Co.
That is the gist of what I have in mind.
Dovecot can I assume, watch the mailfiles in /var/spool/mail?
It can be configured to do so. Or it can be configured to directly receive the mail via pipe from Postfix using LDA or LMTP, and then write it to /var/spool/mail in mbox format, or to user maildirs.
My present method of using inotifywait wrapped in a bash script to tell kmail to go get the new mail via a dbus message has worked well for years. But with no previous experience with imap, I haven't a clue how new mail arrival is handled in that sort of a setup.
Instant notification is built into IMAP4 w/the IDLE command. See: http://en.wikipedia.org/wiki/IMAP_IDLE
Or when it suits more, maybe imapsync. If you keep that chain any local mailer should be able to pick up the locally spooled messages. Maybe you could switch to Maildir as backend, in order to minimizes locking issues. Of course, you could serve that local mail spool with Dovecot to other IMAP or POP3 clients.
Already "pigeonhole"d or "sieve"d into the usual folder format? Once I get the sorting filter rules re manufactured, that would be great!
Not sure what you mean by "the usual folder format". Sieve will sort into your IMAP folders. These may or may not have a 1:1 correlation to filesystem folders. Depends on the mailbox storage format you choose.
Where the email client see's the incoming email already sorted into what are subdirs, in the case of kmail, in the users $HOME/Mail dir. I see claws can see the directory tree kmail has built, but cannot see the kmail messages because it doesn't look into kde-pim/cur. Everything I have pulled from /var/spool/mail/gene with clawsmail has been put as individual numbered files, all in the kmail 'inbox'.
Where I am the only user here, that is not a problem, but it seems to me this individual directory for each mailing list, really should be another tree in /var/mail, but then somehow is it shared such that if I am at one of the machines that run my cnc milling machine or cnc lathe, 150 feet of cat5 & and an 8 port switch, so that what I see from one of those machines is identical to what I would see on this machine?
You also could fetchmail the remote hosts and inject them into a local Dovecot server via LMTP, you can then try to run clamav and spamd from Sieve and you have the other Sieve-capabilities as well.
There ought to be a tut someplace for this, but in my googling for such, nothing has popped up. And wiki2 doesn't seem to get into adequate 'depth', its TBT, closer to a sales pitch than a users howto manual, or I'm not hitting the right links in my 10,000 monkeys like performance. ;)
LTMP is a new acronym to me. Sorry. Synonymous to an MTA? Effectively replacing procmail with dovecot and sieve but still using spamd and clamav?
LMTP, Local Mail Transport protocol, is a subset of SMTP. It can be used locally or over the wire. With the Dovecot LMTP implementation, Sieve takes action on messages when they arrive, and Dovecot's indexes are updated appropriately as well. I'm not sure about spamd and clamav integration here. The vast majority of people using Dovecot deliver the mail via Postfix with LDA or LMTP, and do their AS/AV filtering in Postfix, where SPamassassin and clamav are but two of many possible packages. Many people run both of these via amavisd-new.
Something else to muddy the waters it seems, but I've not actually looked at it either. Possibly my bad.
Are there any better tutorials than Steve Litt's?, which seem to be getting a tad dated now.
I'm not familiar with these tutorials.
He wrote an "escape from kmail' tutorial, 33 pages IIRC, but its a couple years old now.
What I would suggest Gene, if possible, is using the 'standard' Postfit/Dovecot config, doing AS/AV in Postfix, have an upstream system gather the mail from your various POP mailboxes and deliver them to an address hosted by Postfix via SMTP. In other words, push all of the non standard IMAP server methodology away from, upstream of, your Dovecot installation. I'd think one of the mailbox collation services could do this. I.e. POP a dozen mailboxes and forward all the mail to a single SMTP address. Maybe fetchmail can do this. I've never used it.
I actually do that now, popping 3 servers with fetchmail, 2 of which are actually google-mail since my ISP defaulted on keeping a server that actually worked going so they've contracted for gmail now, and one that I refused to use because they had a 5 char maximum passwd, something J-T-R can find in just a few seconds. I like long passwds for any external access.
You may want to ask about this as OT on SDLU. Hundreds of years of combined mail experience there.
I have been reading SDLU for quite some time. The combined level of expertise, and the variety of opinions there are amazing.
However, I would really like to start with some in depth docs, docs I am not having a lot of luck finding. But I am not, as you can see, too bashful to go ask the source. ;)
Thank you Stan.
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: http://coyoteden.dyndns-free.com:85/gene is up! My views http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml If a camel is a horse designed by a committee, then a consensus forecast is a camel's behind. -- Edgar R. Fiedler A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens.
On 7/25/2013 2:45 PM, Gene Heskett wrote:
However, I would really like to start with some in depth docs, docs I am not having a lot of luck finding. But I am not, as you can see, too bashful to go ask the source. ;)
The main problem you're facing right now is that you don't really yet grasp what IMAP is all about. In a nutshell, once you install Dovecot, or any IMAP server, it becomes the single point of control and access to all of your mail. You install an IMAP MUA on each client PC, point these at Dovecot, and you're basically done. They can all be logged into the same account simultaneously, and any new mail will show up in the INBOX on all clients simultaneously, or nearly so.
You typically don't need to configure the clients other than telling them where the server is and plugging in login credentials. The rest is pretty much automatic. Any folders the user has access to should display automatically without needing to manually subscribe. At least this is how it works with Thunderbird.
In other words, with an IMAP server, you simply ditch most of your old way of doing things with your MUAs. The only program that will write/read your mail files will be the IMAP server, Dovecot in this case. All the clients must access mail through an IMAP connection.
-- Stan
On Thursday 25 July 2013 22:45:04 Stan Hoeppner did opine:
On 7/25/2013 2:45 PM, Gene Heskett wrote:
However, I would really like to start with some in depth docs, docs I am not having a lot of luck finding. But I am not, as you can see, too bashful to go ask the source. ;)
The main problem you're facing right now is that you don't really yet grasp what IMAP is all about.
Is wiki2 the sum total of the docs for this? If it is the definitive manual, great.
In a nutshell, once you install Dovecot, or any IMAP server, it becomes the single point of control and access to all of your mail. You install an IMAP MUA on each client PC, point these at Dovecot, and you're basically done. They can all be logged into the same account simultaneously, and any new mail will show up in the INBOX on all clients simultaneously, or nearly so.
This restriction to the INBOX bothers me because the present kmail setup
I'm using has about 55 individual folders such that messages from a mailing
list are sorted by kmail and placed in the appropriate folder/directory.
That includes this mailing list.
You typically don't need to configure the clients other than telling them where the server is and plugging in login credentials. The rest is pretty much automatic. Any folders the user has access to should display automatically without needing to manually subscribe. At least this is how it works with Thunderbird.
I know t-bird can do this message sorting when it is functioning as its own fetchmail as I have done that on my lappy when I am "on the road" which in this case might be yet another tv station that needs a consultant engineer, either to clean up the technical messes other "engineers" have constructed, or in the case of one station in upstate MI that doesn't have engineering staff, so I get flown in with the owners airplane when it upchucks. The market there is way too small to support a local tv station, but the commission put a license there anyway.
But back to t-bird, can it be made to look the same in terms of folders vs folder contents, with say 3 local copies, one on this box, and one each on the boxes running the cnc machines? All accomplished hopefully by getting one copy working, and copying its configs to the other 2, or maybe 3 machines. I use the lappy in the shop to ssh into the cnc boxes so I can sit in relative comfort when making more copies of some part. 90% of the stuff I do is one off's, but I might need a 12 pack of a custom bolt or ??
In other words, with an IMAP server, you simply ditch most of your old way of doing things with your MUAs. The only program that will write/read your mail files will be the IMAP server, Dovecot in this case. All the clients must access mail through an IMAP connection.
Where does dovecot actually keep the email corpus?
I am assuming that is an assignment in 10-master.conf, but there is a quite lengthy list of stuff in the dovecot/conf.d tree that I haven't been able to find in the wiki2 pages. Sure, I can grep for a given variables name, but first, I need to know the name of the variable... Classic new user chicken v egg stuff.
My present du -h on /home/gene/Mail is about 4.8Gb, and the databases kmail keeps for indices etc (and there seems to be an ever growing list of etc's, all convinced they have to have their own copies of everything) aren't there, but total another 16Gb at other locations on my HD's, between soprano and virtuoso. That alone is enough to convince me kmail has got to go. And the kde folks simply will not entertain the suggestion they have bloated it out of viability for even a user willing to restart it daily, and reboot the machine on a weekly basis because it gets so laggy.
Thank you Stan.
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: http://coyoteden.dyndns-free.com:85/gene is up! My views http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml A poet who reads his verse in public may have other nasty habits. A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens.
On 7/25/2013 10:25 PM, Gene Heskett wrote:
On Thursday 25 July 2013 22:45:04 Stan Hoeppner did opine:
On 7/25/2013 2:45 PM, Gene Heskett wrote:
However, I would really like to start with some in depth docs, docs I am not having a lot of luck finding. But I am not, as you can see, too bashful to go ask the source. ;)
The main problem you're facing right now is that you don't really yet grasp what IMAP is all about.
Is wiki2 the sum total of the docs for this? If it is the definitive manual, great.
AFAIK the wiki documentation isn't "complete", but should have everything needed to get a new Dovecot server up and running. What it won't have is anything remotely related to mail file import/migration from a workstation/MUA setup. Dovecot is server application. Any migration docs are geared toward migrating existing mail from other IMAP server platforms, such as Courier or UW-IMAP, etc. It is definitely NOT aimed at the desktop user space, i.e. it's not meant to run concurrently on a *nix PC that is used for desktop GUI applications.
It surely can as it is just another *nix app, but as with any server app one will rely on to be up 100% you really want a dedicated box, UPS, the whole 9 yards. For a SOHO environment with few users it doesn't need to be an expensive hulk of a server, just reliable. The cheapest new PCs usually have a dual/quad core CPU, 4GB RAM, 1TB HD, and ethernet, and this would be overkill performance wise. Get a little 500 KVA APC UPS with data cable and setup apcupsd to do auto shutdown when the battery runs low during an outage.
In a nutshell, once you install Dovecot, or any IMAP server, it becomes the single point of control and access to all of your mail. You install an IMAP MUA on each client PC, point these at Dovecot, and you're basically done. They can all be logged into the same account simultaneously, and any new mail will show up in the INBOX on all clients simultaneously, or nearly so.
This restriction to the INBOX bothers me because the present kmail setup I'm using has about 55 individual folders such that messages from a mailing list are sorted by kmail and placed in the appropriate folder/directory.
That includes this mailing list.
I've never used kmail. Does it have an IMAP connector? If so, once you have the Dovecot server up and working and kmail configured and working with IMAP, you'd simply copy the emails in the current folders over to newly created folders of the same name. AFAIK you can't just do any drag 'n drop existing mail folders.
You typically don't need to configure the clients other than telling them where the server is and plugging in login credentials. The rest is pretty much automatic. Any folders the user has access to should display automatically without needing to manually subscribe. At least this is how it works with Thunderbird. ... But back to t-bird, can it be made to look the same in terms of folders vs folder contents, with say 3 local copies, one on this box, and one each on the boxes running the cnc machines? All accomplished hopefully by getting one copy working, and copying its configs to the other 2, or maybe 3 machines. I use the lappy in the shop to ssh into the cnc boxes so I can sit in relative comfort when making more copies of some part. 90% of the stuff I do is one off's, but I might need a 12 pack of a custom bolt or ??
If you install default Tbird on each machine, all that's required afterward is to create an account profile, input the IMAP server IP address, SMTP relay server address, and enter the username/pwd when prompted. This assumes the user already exists on the Dovecot server. At that point the view and folder list should be identical on each Tbird.
In other words, with an IMAP server, you simply ditch most of your old way of doing things with your MUAs. The only program that will write/read your mail files will be the IMAP server, Dovecot in this case. All the clients must access mail through an IMAP connection.
Where does dovecot actually keep the email corpus?
If you're referring to the user mail files, they are stored in the location you specify in dovecot.conf. This will be a local filesystem directory on the server box. All mail for all users will be stored here, once. You will no longer store any mail files on the client PCs. By having all the mail on the server you can access it from any computer running an MUA. And in fact from anywhere in the world with an internet connection, assuming you configure your local internet router properly. You can also install an webmail server that connects to Dovecot via IMAP. Then you can access the emails from any device with a web browser and net connection. I use Roundcube for this. Other options are SoGo, Squirrelmail, etc.
In fact if you install such a webmail server alongside Dovecot, you don't need to have an MUA on any client PC. Just Firefox, or your favorite browser.
I am assuming that is an assignment in 10-master.conf, but there is a quite lengthy list of stuff in the dovecot/conf.d tree that I haven't been able to find in the wiki2 pages. Sure, I can grep for a given variables name, but first, I need to know the name of the variable... Classic new user chicken v egg stuff.
Set the mail_location in conf.d/10-mail.conf
You need to read up on the various mailbox formats before choosing one. If unsure, ask the list.
My present du -h on /home/gene/Mail is about 4.8Gb, and the databases kmail keeps for indices etc (and there seems to be an ever growing list of etc's, all convinced they have to have their own copies of everything) aren't there, but total another 16Gb at other locations on my HD's, between soprano and virtuoso. That alone is enough to convince me kmail has got to go. And the kde folks simply will not entertain the suggestion they have bloated it out of viability for even a user willing to restart it daily, and reboot the machine on a weekly basis because it gets so laggy.
16-20GB of mail files for one user, or a handful of users, is ridiculous. If you have lots/large attachments in those email files detach those and save them appropriately as normal files BEFORE you start copying your existing mail to the new Dovecot server. It would make much sense to install Samba on your Dovecot server box and save all those attachments to a directory on the server.
FYI I have 82,600+ emails in my two dozen or so IMAP mailbox folders. Including Dovecot indexes, the consumed space on disk is only 1.1GB. Most is archived list mail. Very few attachments. The Dovecot indexes alone are 160MB of that, slightly more than 10 percent.
Thank you Stan.
No problem. I wouldn't say getting Dovecot running the first time is difficult for a first time user, if you're doing a standard Dovecot/Postfix setup with an MX record and delivery to your domain via smtp. In your case it's going to be much more difficult, because your current architecture is an ad hoc collection of PCs, and you have no central mail delivery to a local domain. The latter, with many external addresses/mailboxes, is going to be the hard part.
-- Stan
participants (4)
-
Ben Morrow
-
Gene Heskett
-
Stan Hoeppner
-
Steffen Kaiser