> We're working on a roadmap for mailmanager over the next 12 months or
> so. And I figured that you folk were the best people to ask - after
> all, you're using it in anger every day. :-) So what would you like to
> see improved? What new features?
a. New requests marked as 'New' not 'Open'
b. Ability to set user defined categories by expression (regular or
SQL), e.g. If subject contains "Maxsurf" set Product to "MS"
c. Ability to assign on receipt if subject contains specific words,
e.g.If subject contains "Maxsurf" assign to Bob. (this would have some
performance degradation)
d. Archive attachments for old requests to a folder
e. Give me time, I'll think of more...
> How would you feel about there being a separate daemon running to handle
> the incoming email, completely separately from Zope? This would
> basically be a replacement to the MailCheckThread and the MMGetMail.py
> script. One option is to create a separate ZServer which is started
> along with the main Zope server, the other is to create a completely
> independent daemon, in the same kind of way as Mailman has its qrunner
> daemon.
I think you also have to cater for those running Zope on a Windows
machine, so need to think of a service too.
> A pluggable interface for filtering incoming messages - anti-virus, spam
> filtering, full regular-expression filtering. Fair enough, most of this
> can be done in the MTA itself but, particularly with the spam filtering,
> we can improve any Bayesian data set by there being a user interface
> function to verify what truly is spam & ham.
A word of caution - false positives can cause more work than it saves. I
would certainly leave some filtering as a manual task and labelling
suspect emails is fine.
> Personally, I find the supporter feature confusing and misleading.
> Instead I'd like to redo it, more or less in the same way as I recall
> request tracker's implementation - with parents, children, depends on
> and depended on by. OK, I haven't actually used rt in a few years now,
> but I'm sure I remember it being more intuitive and helpful.
The constraints of one on the other needs to be selectable. If one
request spawns another, it doesn't necessarily need to wait for that one
to be closed. If they are constrained then it may be nice to use
recursive closure
> OK, that's all I can remember for now. So which of these ideas are
> good, which are really, really bad? :-) What else do you want to see?
Hold that space...
Ron

> MySQL has had transaction support since they incorporated their InnoDB
> backend - a couple of years ago, I think. But then again, Andy is my
> pointy-haired boss... :-)
Your quite right Graeme. If I was going to use transactions, its just a
case of preference to use Postgres as I think it does the job better.
For raw speed MySQL is by far the best option.
> Or you could outsource it to http://www.logicalware.net/ ... :-)
So long as I can come back to Edinburgh and help you do it.
Ron

Graeme Mathieson <mathie@...> on 2/28/05 wrote:
>We're working on a roadmap for mailmanager over the next 12 months or=20
>so. And I figured that you folk were the best people to ask - after=20
>all, you're using it in anger every day. :-) So what would you like to=20
>see improved? What new features?
experience has been largely joyful so far :)
>How would you feel about there being a separate daemon running to=20
>handle the incoming email, completely separately from Zope? This would=20
>basically be a replacement to the MailCheckThread and the MMGetMail.py=20
>script. One option is to create a separate ZServer which is started=20
>along with the main Zope server, the other is to create a completely=20
>independent daemon, in the same kind of way as Mailman has its qrunner=20
>daemon.
what is the benefit exactly? so far i am content with the cronjob.
having another daemon to monitor doesn't sound like much fun.
>Right, next up, we're going to have better threading support for=20
>messages - instead of relying purely upon a tag in the subject - using=20
>Message-Id, In-Reply-To and References. Maybe in the future, this=20
>could come through to the user interface by having a tree-style=20
>interface of messages and replies.
current one works for me. maybe have an option for keeping it flat?
>A pluggable interface for filtering incoming messages - anti-virus,=20
>spam filtering, full regular-expression filtering. Fair enough, most=20
>of this can be done in the MTA itself but, particularly with the spam=20
>filtering, we can improve any Bayesian data set by there being a user=20
>interface function to verify what truly is spam & ham.
sounds like bloat. I am happy with the MTA doing that. better regexp
might be nice tho.
>Personally, I find the supporter feature confusing and misleading. =20
>Instead I'd like to redo it, more or less in the same way as I recall=20
>request tracker's implementation - with parents, children, depends on=20
>and depended on by. OK, I haven't actually used rt in a few years now,=20
>but I'm sure I remember it being more intuitive and helpful.
interesting... yes the current one is kind of a pita.
some ideas:
- can we get ram usage down? MM says it uses around 80m of hdd to store
our 11K tickets and ram usage is 420-440M. That's with a ZEO backend.
that does not bode well for the future. why does it use so much ram?
(right now using zope 274, python 2.4, situation has persisted across
versions for some time.) is it loading more catalog records or tickets
into memory than it needs to?
- maybe this does not need to be or even shouldn't be a zope app? maybe
run it with mod_python or twisted?
- would definitely like to see some integration with plone so you can
plug the database of tickets into a portal and enable users to be able
to search/view their own tickets and file new ones (without needing to
auth). we have a major knowledge base of 11K tickets all locked up where
its no good to anyone. i know i could create users in MM but when you
have more than about 50 of them it becomes impractical. we could
potentially plug our ldap store in there tho ...
- integration with client stores. for any large organization there will
probably be a database of clients. having client data integrated with MM
makes it easier to reply quickly and accurately to queries (at least for
support). I have some simple code to integrate MM with LDAP and show
data in the "TICKET DETAILS" slot that i can share. Working on the same
for MySQL.
- the ability to have a cronjob that will remove all spam from MM would
be nice. manually doing it becomes tiring.
hth :)
<-->
george donnelly ~ http://www.zettai.net/ ~ "Quality Zope Hosting"
Complete Zope Hosting ~ Dedicated Servers ~ Plone Hosting Solutions
Y/AIM: zettainet ~ Jabber: info@... ~ Sales: (866) 408-5395

Hi,
We're working on a roadmap for mailmanager over the next 12 months or
so. And I figured that you folk were the best people to ask - after
all, you're using it in anger every day. :-) So what would you like to
see improved? What new features?
Personally, I've got a few things I'd like to improve. You already
know about switching to a more scalable database backend - that's our
absolute first priority and probably the only major new feature we'll
see in the next release.
How would you feel about there being a separate daemon running to
handle the incoming email, completely separately from Zope? This would
basically be a replacement to the MailCheckThread and the MMGetMail.py
script. One option is to create a separate ZServer which is started
along with the main Zope server, the other is to create a completely
independent daemon, in the same kind of way as Mailman has its qrunner
daemon.
Right, next up, we're going to have better threading support for
messages - instead of relying purely upon a tag in the subject - using
Message-Id, In-Reply-To and References. Maybe in the future, this
could come through to the user interface by having a tree-style
interface of messages and replies.
A pluggable interface for filtering incoming messages - anti-virus,
spam filtering, full regular-expression filtering. Fair enough, most
of this can be done in the MTA itself but, particularly with the spam
filtering, we can improve any Bayesian data set by there being a user
interface function to verify what truly is spam & ham.
Personally, I find the supporter feature confusing and misleading.
Instead I'd like to redo it, more or less in the same way as I recall
request tracker's implementation - with parents, children, depends on
and depended on by. OK, I haven't actually used rt in a few years now,
but I'm sure I remember it being more intuitive and helpful.
OK, that's all I can remember for now. So which of these ideas are
good, which are really, really bad? :-) What else do you want to see?
--
Mail: mathie@... | Web: http://woss.name/
AIM: Math1e | PGP: 1024D/D72F2737

On 27 Feb 2005, at 23:24, Ron Goodwin wrote:
> I would have to agree with your choice, primarily for transaction
> support - not for performance though. At the end of the day we all
> have our personal preferences but are often overruled by workplace
> (pointy heads) constraints.
MySQL has had transaction support since they incorporated their InnoDB
backend - a couple of years ago, I think. But then again, Andy is my
pointy-haired boss... :-)
> I am looking into perhaps hosting the database on a seperate machine,
> which I will administer.
Or you could outsource it to http://www.logicalware.net/ ... :-)
--
Mail: mathie@... | Web: http://woss.name/
AIM: Math1e | PGP: 1024D/D72F2737

I would have to agree with your choice, primarily for transaction
support - not for performance though. At the end of the day we all have
our personal preferences but are often overruled by workplace (pointy
heads) constraints. Go with what is best for the product, scalability
and performance. I am looking into perhaps hosting the database on a
seperate machine, which I will administer. Fallback position is that we
stick with Ver.1.1 when it is released - nudge nudge ;) ;)
Ron
Andrew Veitch sent the following on 26/02/2005 4:48 PM:
> Ron -
>
> I have a personal preference for PostgreSQL over MySQL but I'm sure we
> would have support for both. In terms of admin overhead I think SQLite
> is less work than the ZODB - which itself is very low maintenance. It
> doesn't even have a server process, SQLite clients simply open the
> database file. The only maintenance I think you would need to do would
> be to back up the database which is copying a single file.
>
> I certainly hope that you do continue to use the product, your feedback
> and bug reports have been really helpful.
>
> Best regards
>
> Andrew
>
> On 22 Feb 2005, at 23:35, Ron Goodwin wrote:
>
>> This would pose a dilema for us and would probably put the last nail
>> in the coffin for our continued use of MM. It took a lot of marketing
>> to persuade our small organization to adopt the use of Zope which is
>> only run to support MM - and now has over 400Mb of data.
>>
>> Our problem is the number of databases we have to support on a daily
>> basis - e.g. MySQL for website and SQLServer for products. Yes, some
>> bright spark thought WebGUI was better than Plone.
>>
>> To introduce another Db would be the death knell for MM unless we can
>> hook it up to MySQL or SQLite has no admin overhead.
>
>

On 26 Feb 2005, at 08:36, Andrew Veitch wrote:
> This looks really interesting - it would certainly solve the
> scalability problems of the Catalog. It wouldn't solve our problems
> with the ZODB unfortunately.
I must admit I haven't looked at the catalogue in nearly enough detail,
but the idea I have in the back of my head is to produce a Catalog
interface which just directly queries the backend SQL database,
effective passing off the problem to the database itself. After all,
I'm sure most db vendors have already put lots of effort into fast
performance indexing. But I'm not sure if/how it will fit into the
existing Catalog interface.
It's on my todo list. :)
--
Mail: mathie@... | Web: http://woss.name/
AIM: Math1e | PGP: 1024D/D72F2737

Ron -
I have a personal preference for PostgreSQL over MySQL but I'm sure we
would have support for both. In terms of admin overhead I think SQLite
is less work than the ZODB - which itself is very low maintenance. It
doesn't even have a server process, SQLite clients simply open the
database file. The only maintenance I think you would need to do would
be to back up the database which is copying a single file.
I certainly hope that you do continue to use the product, your feedback
and bug reports have been really helpful.
Best regards
Andrew
On 22 Feb 2005, at 23:35, Ron Goodwin wrote:
> This would pose a dilema for us and would probably put the last nail
> in the coffin for our continued use of MM. It took a lot of marketing
> to persuade our small organization to adopt the use of Zope which is
> only run to support MM - and now has over 400Mb of data.
>
> Our problem is the number of databases we have to support on a daily
> basis - e.g. MySQL for website and SQLServer for products. Yes, some
> bright spark thought WebGUI was better than Plone.
>
> To introduce another Db would be the death knell for MM unless we can
> hook it up to MySQL or SQLite has no admin overhead.
--
Logical Progression Ltd, 20 Forth Street, Edinburgh EH1 3LH, UK
Tel: +44 (0)131 550 3733 Web: http://www.logicalprogression.net/

On 22 Feb 2005, at 15:59, Ausum Studio wrote:
> Sounds interesting. Anyway I'd suggest to consider to provide any
> support to relational databases through APE.
I've spent 2 weeks evaluating APE for a customer. The conclusion was
that APE is still beta quality. Computer Associates are doing a lot of
work with it for their BDM product so it may improve.
> On the main subject, a client of ours is considering MailManager as
> their local mail management solution, but due to their mail servers
> are remote, I've been asked on the reliability of MM when dealing with
> remote POP mail downloads.
Most of the customers on the commercial service use POP and we've not
had any reliability problems with the POP element. Mail is only deleted
from the POP server after it is downloaded and committed to the Zope
Database so if anything goes wrong during the download mail won't be
lost. There is logging - it just goes into the standard Zope event log.
A
--
Logical Progression Ltd, 20 Forth Street, Edinburgh EH1 3LH, UK
Tel: +44 (0)131 550 3733 Web: http://www.logicalprogression.net/

On 22 Feb 2005, at 23:35, Ron Goodwin wrote:
> To introduce another Db would be the death knell for MM unless we can
> hook it up to MySQL or SQLite has no admin overhead.
Our current plan is that it should hook into any database which has a
database adaptor for Zope. The reason for mentioning SQLite is that
one of our priorities is to have a product which works straight out of
the box, not requiring the setup of any additional storage backends. I
wouldn't say SQLite has *no* admin overhead, but it appears to be no
different from the care and feeding of a Data.fs or a BerkeleyDB. (Or
possibly even less admin overhead than a Berkeleydb database, since my
subversion repository does have a habit of going in the huff
occasionally!)
I'm still at the stage of doing performance testing, but the system
I've got on my laptop for injecting mail into a mailmanager database
really rocks compared to injecting mail into a mailmanager through
MMMailIn.py. If I can get a similar performance boost from hooking the
Zope web interface into the database, we're going to see a *massive*
improvement in the speed and usability of mailmanager by version 1.2!
--
Mail: mathie@... | Web: http://woss.name/
AIM: Math1e | PGP: 1024D/D72F2737

Andrew,
This would pose a dilema for us and would probably put the last nail in
the coffin for our continued use of MM. It took a lot of marketing to
persuade our small organization to adopt the use of Zope which is only
run to support MM - and now has over 400Mb of data.
Our problem is the number of databases we have to support on a daily
basis - e.g. MySQL for website and SQLServer for products. Yes, some
bright spark thought WebGUI was better than Plone.
To introduce another Db would be the death knell for MM unless we can
hook it up to MySQL or SQLite has no admin overhead.
Regards
Ron
QA/SWTest Tel/Fax: +61 8 9335 1522 / 1526
Formation Design Systems Support: support@...
PO Box 1293, Fremantle Email: rong@...
W. Australia, WA6160 http://www.formsys.com
Andrew Veitch sent the following on 22/02/2005 6:04 PM:
> On 21 Feb 2005, at 17:42, george donnelly wrote:
>
>> we started using MM about 14 mos ago and have close to 10K emails in
>> there. Zope uses more than 400M RAM, and this with a ZEO backend. would
>> be great if we could get that down to a more reasonable amount. we'd be
>> willing to pitch in.
>
>
> That's great.
>
> At the moment we are considering using SQLite as the engine. SQLite
> could be embedded in the main MailManager product, SQLite is similar to
> Gadfly in that there is almost no installation or configuration
> required. We would also make sure that the Migration tab would migrate
> all existing tickets into the new database.
>
> For most users SQLite would be fine, but for our hosted service or some
> of the bigger sites SQLite could be replaced with PostgreSQL or Oracle
> or whatever to allow really big scaling up.
>
> Graeme's going to do some testing this week so we'll see how the
> performance compares before doing anything.
>
> Andrew
>

On Tue, 22 Feb 2005 10:04:50 +0000, Andrew Veitch
<andrew@...> wrote:
(...)
>
> That's great.
>
> At the moment we are considering using SQLite as the engine. SQLite
> could be embedded in the main MailManager product, SQLite is similar to
> Gadfly in that there is almost no installation or configuration
> required. We would also make sure that the Migration tab would migrate
> all existing tickets into the new database.
>
> For most users SQLite would be fine, but for our hosted service or some
> of the bigger sites SQLite could be replaced with PostgreSQL or Oracle
> or whatever to allow really big scaling up.
Sounds interesting. Anyway I'd suggest to consider to provide any
support to relational databases through APE.
On the main subject, a client of ours is considering MailManager as
their local mail management solution, but due to their mail servers
are remote, I've been asked on the reliability of MM when dealing with
remote POP mail downloads. For instance, is there a log file to track
download failures and/or automatically resume aborted downloads? Is
there a way for us developers to add a size threshold to avoid large
downloads (without touching the mail server configuration)? This is
people who heavily use emailing, and therefore they depend on the mail
they get but also on the mail they know for sure they didn't get. I'm
going to perform tests on my own, but also I'd like you members of MM
list to share experiences on issues like these, whether the case.
Thanks in advance,
Ausum
> Graeme's going to do some testing this week so we'll see how the
> performance compares before doing anything.
>
> Andrew
>
> --
> Logical Progression Ltd, 20 Forth Street, Edinburgh EH1 3LH, UK
> Tel: +44 (0)131 550 3733 Web: http://www.logicalprogression.net/
>

I don't know about memory consumption, but if you're looking purely at
performance you may want to check out ZSQLCatalog -
http://www.erp5.org/workspaces/project/zsqlcatalog/
Sincerely,
Jon Roberts
"God grant that in America true religion and civil liberty
may be inseparable and that the unjust attempts to destroy
the one, may in the issue tend to the support and
establishment of both."
-- John Witherspoon, signer of the Declaration of
Independence

On 21 Feb 2005, at 17:42, george donnelly wrote:
> we started using MM about 14 mos ago and have close to 10K emails in
> there. Zope uses more than 400M RAM, and this with a ZEO backend. would
> be great if we could get that down to a more reasonable amount. we'd be
> willing to pitch in.
That's great.
At the moment we are considering using SQLite as the engine. SQLite
could be embedded in the main MailManager product, SQLite is similar to
Gadfly in that there is almost no installation or configuration
required. We would also make sure that the Migration tab would migrate
all existing tickets into the new database.
For most users SQLite would be fine, but for our hosted service or some
of the bigger sites SQLite could be replaced with PostgreSQL or Oracle
or whatever to allow really big scaling up.
Graeme's going to do some testing this week so we'll see how the
performance compares before doing anything.
Andrew
--
Logical Progression Ltd, 20 Forth Street, Edinburgh EH1 3LH, UK
Tel: +44 (0)131 550 3733 Web: http://www.logicalprogression.net/

Just wanted to give a quick update of latest news.
1.1 release candidate 5 is a pretty solid and ready for release. We
have already migrated our customers on our hosted service to it with no
problems reported. There's some translation work being done and once
this is complete we will release a 1.1 final.
Our commercial service has been doing pretty well which has led us to
do some more work on scaling MailManager up. Within the next 6 months
some of our customers will be over a million tickets and as we are
beginning to step up our marketing we're also likely to be seeing an
increase in the number of customers too.
I know that quite a few users of the open source product are also
seeing pretty dramatic growth in their users and tickets.
I've been corresponding with an ex-Zope corp developer who may do some
consulting for us on scaling up the ZODB/ZCatalog or alternatively we
may need to look at something else - such as a relational database.
Currently we're doing lots of testing to see where the limits of the
present architecture are. I'll post again when we have more numbers.
I'd be interested in views on this, particularly from anyone that's
really pushing the limits of the present architecture.
Andrew
--
Logical Progression Ltd, 20 Forth Street, Edinburgh EH1 3LH, UK
Tel: +44 (0)131 550 3733 Web: http://www.logicalprogression.net/

Hello,
All my auto reply mails fail.
In MailManager a mail adres is as follow: (This is standing in the
purple bar above Subject:)
"Full Name"emailadres ("Martin
Koekenberg"mailmanager@...)
The auto reply is send to the last part of the fullename with my
defauldomain after the @..(Koekenberg@...,
digital-adventures.nl is my default domain in my mailserver) I Think
it's sends to "Koekenberg" and that the mailserver add the
"@digital-adventures.nl"part.
Is this a wrong setting in Mailmanager ??
Greetings,
Martin Koekenberg

Hi Josh
I think this is one of three things:
1. The mail server is configured with the wrong address - it should be
127.0.0.1 you can check in the 'Properties' tab on the main Mail
Manager instance.
2. The mail server is down
3. There's a firewall preventing MM from accessing the server (I've
been bitten by this one before!)
Hope that helps
Andrew
On 10 Feb 2005, at 04:43, joshua wrote:
> hi to All
>
> I am running MailManager v1.0 on a Win2k machine, which also runs a
> mail server. I can receive mail without a problem but cant send any.
> Program responds with
> 'Message not send: problem conntecting to mail server'
>
> Thanks in advance for any light anyone can shed
>
> Josh
--
Logical Progression Ltd, 20 Forth Street, Edinburgh EH1 3LH, UK
Tel: +44 (0)131 550 3733 Web: http://www.logicalprogression.net/

hi to All
I am running MailManager v1.0 on a Win2k machine, which also runs a
mail server. I can receive mail without a problem but cant send any.
Program responds with
'Message not send: problem conntecting to mail server'
Thanks in advance for any light anyone can shed
Josh

Hi
All of the image buttons are being moved to text and CSS. I'm just
waiting for this to come back from the interface designer hopefully it
will be done this week. We'll make a new release 1.1.1 which will have
this change.
For the translation all you will need to do is go into the i18n
directory copy the file mailmanager.pot to mailmanager.xx where xx is
the code for the language. I think pt is the code for Portuguese. The
file is quite big because of all the help text but I'm expecting that
most translators will just translate the main section.
Thanks for your work - a Portuguese translation will be a great!
Andrew
On 5 Feb 2005, at 11:11, Erick Alves Rezende wrote:
> Hi,
>
> I see that the new 1.1 release will suport i18n, great feature! Is it
> possible to translate the image buttons? If I have them translated to
> Portuguese, in which dir should I put?
>
> Regards,
> Erick
--
Logical Progression Ltd, 20 Forth Street, Edinburgh EH1 3LH, UK
Tel: +44 (0)131 550 3733 Web: http://www.logicalprogression.net/