multiple accounts in kmail
John Woodhouse
a_johnlonger at yahoo.com
Wed Jun 15 23:49:33 BST 2011
----- Original Message -----
> From: Duncan <1i5t5.duncan at cox.net>
> To: kde at mail.kde.org
> Cc:
> Sent: Tuesday, 14 June 2011, 15:05
> Subject: [kde] Re: multiple accounts in kmail
>
>G ary Roach posted on Mon, 13 Jun 2011 19:10:09 -0700 as excerpted:
>
>> I am trying to consoidate 2 email accounts onto the same machine but
>> still keep them separated. I wish to use kmail. I am running kde 4.4.5
>> on a Debian Linux operating system. My problem is this:
>
>> I have two email accounts xxxxxx at verizon.net and
>> yyyyyy at verizon.net. Both send mail to outgoing.verizon.net and receive
>> from incoming.verizon.net. They now reside on a Win2k box and a Debian
>> linux box respecively. I wish to keep the two accounts completely
>> separate but wish to put both on the linux box. In addition, I need to
>> transfer my mail archives from thunderbird and iceweasel. I have read a
>> lot of stuff on the net but have found most out of date and confusing.
>> Can anyone lay out a road map that will allow me to set up these 2
>> accounts so they will co-exist with out being intermingled.
>>
>> My present file structure is:
>> home/xxxx/.kde/share/apps/kmail/Mail
>
> First, let me commend you for both including critical version information
> and technical detail, AND proper sanitation of irrelevant personal
> information such as the exact email addresses and the precise name of
> your user's home dir. Few enough get the first part right; even fewer
> BOTH get that right and properly sanitize the data they do post. Your
> post thus stands as a shining example of how to ask a question on the
> lists the /right/ way! =:^)
>
> Beyond that... something you are likely already aware of, but the first
> thing that occurs to me is that 4.4.5 is somewhat dated. I've been
> recommending 4.5.4 or 4.5.5 as very stable upgrades with a better overall
> kde experience than 4.4 and earlier provided. In fact, my repeated
> position is that (the later monthly updates of) 4.5 was the first kde4
> version I felt comfortable recommending to pretty much everyone -- what
> SHOULD have been 4.0. 4.4 meanwhile was close, I've compared it to
> release candidate quality, but not yet quite there. So overall, you're
> slighting your own experience of the best kde has to offer, by remaining
> with 4.4. (4.6, OTOH, I'd NOT recommend yet, except for those on
> distributions which have already gotten rid of hal, and then I'd
> definitely recommend sticking with 4.6.0 or 4.6.1, as 4.6.2 and 4.6.3
> were buggy for many. 4.6.4 is just out and may be better, but I've not
> had a chance to build (as I'm on Gentoo) and test it yet, so 4.5.5 for
> those not yet migrated off of hal and 4.6.0 for those already migrated,
> remain my recommendations, probably for another week or so anyway until I
> can build and get at least a few days on 4.6.4.)
>
> That's in the context of kde4 in general. As you may know, kmail/kdepim,
> however, need treated separately, because they only had micro updates
> during 4.5 and early 4.6, remaining at the 4.4 minor version level, with
> 4.4.11.1 beias you may know,ng the latest in that series. The reason
> behind this is that the planned upgrade to the akonadi backend was not
> judged to be ready for general public usage yet, so in the meantime they
> simply micro-updated in ordered to maintain compatibility with the rest
> of the kde 4 platform as it moved to 4.5 and then 4.6. (In this the
> kdepim folks seem to have learned from the far too early christening of
> kde 4.0 and the general declaration of 4.2 and 4.3 as ready for the
> masses when that clearly wasn't the case, costing kde dearly in lost
> reputation, and the kdepim folks chose not to repeat the same mistake,
> erring if anything on the side of caution.)
>
> So until just this week, kdepim and with it kmail and kontact remained at
> a bug-fixed 4.4 level. Just this week, however, the long awaited general
> release of the akonadified kmail/kontact2 occurred. However again, I've
> not done the upgrade myself yet, so will withhold evaluation thereof,
> except to commend the kdepim folks for all their caution, with the
> comment that I'm very optimistic, expecting a much smoother experience as
> a result. =:^)
>
> The reason that bit, particularly the last about the upgrade to kmail2
> (to go with kde 4.6.4 and later), comes up, is to point out that the 4.4
> series kmail you're running now is a stopgap. 4.4 had already migrated
> the address book to akonadi, and the integration between it and the not
> yet migrated kmail wasn't as good as it might have been. Further, active
> development on that branch hasn't occurred for some time, as it was
> considered to be almost wasted effort, since the new version was so close.
>
> As such, while what you have should be quite stable, keep in mind its
> status and that yet another major upgrade and database conversion is in
> the cards for whenever you upgrade to later kde 4.6 or 4.7 or whatever.
> Depending on your situation and on the Debian upgrade timetable which I
> don't know, being on Gentoo, it may be that you wish to hold off on that
> migration until you can do it to the new akonadified version, thereby
> avoiding having to do yet another conversion presumably soonish
> thereafter. I'm not saying DON'T do the migration now. I'm simply
> pointing out some factors you will likely wish to keep in mind. You may
> know about them already or not, and it may affect your current decision
> or not, but it's good information to have in any case. And you mentioned
> out of date and confusing information... this is a heads-up that it just
> got MORE so. =:^(
>
> To the question, then... assuming you're continuing the conversion with
> kdepim 4.4.
>
> I'm rather unclear on what you mean when you say you wish to keep the
> accounts "completely separate", but with the implication and tone of
> the
> question being that you intend to access them in the same kmail instance
> in the same Linux user account. To me, that doesn't seem to be
> "completely separate" at all. To me, "completely separate"
> would be
> accessed from two "completely separate" Linux user accounts, two
> different home dirs (/home/xxxx/ and /home/yyyy/ to use your sanitized
> terminology), etc. To me, accessing them both from the same kmail
> instance isn't what I'd call completely separate, but rather, simply two
>
> different email accounts accessed from the same kmail, with the same
> local storage, yet that seems to be what you're implying.
>
> It's definitely possible to have two "completely separate"
> accounts, but
> then I don't see the problem. You'd have two separate users, each with
> their own login and each with their own separate local kmail config and
> storage, so what's the problem? Thus, I can only assume you do NOT mean
> the "completely separate" you so clearly stated, but instead, want a
> combined local config, but maintaining the separate email addresses and
> possibly separate inboxes, etc.
>
> This too is quite possible, with the degree to which the mail from the
> separate accounts is kept separate, locally, entirely up to you. In
> fact, it's much the way I run here, with several separate public mail
> accounts, most on one domain, one on a former provider's domain, and one
> entirely local-machine account handling mail from local machine cronjobs
> and the like. Incoming from the multiple addresses on the main domain is
> all from the one server (corresponding to your incoming.verizon.net),
> with the other domain's server polled for that address separately (and
> the local machine mail appearing in a special maildir folder I have setup
> for the purpose). Outgoing for both the main domain and the old one goes
> thru the same main domain outgoing server, with only the from address set
> to the old domain, for mail I wish to send with that address.
>
> Incoming mail is sorted using the same common set of filters. One filter
> for each address adds a header to the mail indicating which address it
> came in on, just in case the mail itself doesn't list that. Rather than
> a single inbox, however, or even one per mail address, I use filters to
> sort all incoming mail by sender (family, friends, work, etc), subject,
> etc. However, it's entirely possible to sort into inbox based on address
> the mail was sent to, if desired.
>
> The key to it all, however, at least from my perspective, is filters.
> Get your filters properly setup for what you want to do, and you
> shouldn't have problems. Screw that up and you'll never get the
> separation you want. But how/what you filter on and what you do with
> those filters (adding additional headers, sorting into separate folders,
> forwarding, etc) is of course up to you.
>
> --
> Duncan - List replies preferred. No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master." Richard Stallman
>
> ___________________________________________________
> This message is from the kde mailing list.
> Account management: https://mail.kde.org/mailman/listinfo/kde.
> Archives: http://lists.kde.org/.
> More info: http://www.kde.org/faq.html.
>
I'm using kde 4.6.0 - opensuse 11.4. No real problems or irritations really except kmail filters but a base lib update seems to have fixed that. The filters are now working as far as I can tell. I use them to split off a number of email addresses, my wife's for instance and further splitting on contents. This isn't really treating them entirely separately. One thing that may not work is trying to run 2 instances of kmail. This was a problem in the past and I suspect it's now trapped out even in cases where there would be no conflict. 2 users would definitely work and keep everything totally separate.
John
;-) A crippled mount-cifs has been the only major irritation.
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
More information about the kde
mailing list