Re: Proposed change for subscriptions...
s. keeling said:
> Incoming from Steve Lamb:
>> Like, say, received multiple email accounts through IMAP/POP and
>> keep the entire exchange separate for every account without having the
>> overhead of multiple email clients.
> That doesn't sound too difficult a problem for procmail (or
> mailfilter) to sort out.
Actually it is impossible for those tools alone to sort out.
> Perhaps your idea of a solution to the problem needs rethinking. Why
> are you insisting on using such a complex system?
Uh, because it is simplier than the simple system? It's like asking why
people use a calculator after their had batteries have run out and
pointing out the far simpler pencil and paper has no batteries to run
out.
The key phrase above is "keep the entire exchange separate for every
account." ENITRE... EXCHANGE. Procmail and mailfilter do not to my
knowledge operate on outbound mail, only incoming mail.
About a decade ago I grew quite accustomed to havin my work and home
mail checked by a single client (then PMMail) and having each account
completely separate within the clint. They are so compartmentalized
that I could move one directory and the account disappears. I move that
directory back and the account reappears.
What I mean is that incoming mail comes from the appropriate server,
outboung mail goes to the approriate server, the sent mail is stored
separately, the filters do not act upon any mail but mail destined for
that account, and amazingly enough I can create a folder under one
account and that's the beginning and end of the configuration for that
account.
Now, what's the similar hoops for the current mail chain de jour?
Fetchmail, Exim, Procmail, Mutt. First off I have to configure
Fetchmail to get the mail for each account. Mind you this is completely
worthless for IMAP accounts by reducing them to glorified POP accounts.
Then I have to cram it through Exim, mering the two mail streams and
ignore it's filtering for the almighty Procmail. I have to then
configure Procmail to split out the mail streams and on every filter put
in checks to ensure that one account's filter doesn't act on another
account's mail. Once I've jumped that hoop I now have to configure mutt
*per folder* to use the correct from: address, put the outbound
sent/postponed mail in the proper folders. After that I have to go back
to Exim and configure it for separate smart hosts based on the from
field put into mutt. If I want to add a folder for mail I can't just
add it. I have to add it and mess with mutt's configuration all over
again.
Any time I want to add an account I need to tell PMMsail (now
Thunderbird) exactly 3 things. Incoming server, outgoing server, email
adress associated with that account. From that all other settings work
as desired.
Any time I want to add an account to the mail chain I have to configure
fetchmail, exim incoming, procmail, mutt (more folder hooks galore!),
then exim outbound.
Sorry, but the mail tool chain isn't the simple tool, it's the complex
one. I much prefer my calculator to your pen and paper, even if every
now and again I have to replace the batteries.
> Perhaps that's what needs re-working, not Debian list posting rules.
No. The Debian rules need the re-working because the list maintainers
are being irresponsible and careless with the addresses in their care.
My problems are ancilliary to that basic fact.
> Yes, I am suggesting
> you change. You're insisting your system isn't working for you.
Might help if you suggested something comparable in usefulness instead
of a huge step backwards. For the relatively few warts Thunderbird
poses to me your alternative would take hours of configuration (compared
to TBird's minutes initially), lots of upkeep (compared to TBird's
virtually none) as time went by and would not come close to what TBird
offers me. IMAP accounts where *all* mail (postponed, sent, incoming,
filtered) is stored and access from server side & sensible defaults
based on accounts instead of forcing mail to remain stangnate in the 1
user-account, 1 mail-account '80s.
--
Steve Lamb
Reply to: