On May 11, 2005, at 17:57, PowerMail Engineering wrote:
> Mark Smith wrote:
>
>> - IMAP support
>>
>> - simultaneous connections to more than one server ?
>> - filtering of messages into server-side mailboxes ?
>> - syncing with IMAP mailboxes other than inbox ?
>>
>> - PM Search
>>
>> - savable queries ?
>> - smart queries ?
>
> These are feature that we consider for a future version, but it
> will not
> happen in the short term.
Ack.
>> - Spotlight
>>
>> - indexing (and display) of additional attributes for Spotlight
>> searching ?
>
> Indexing is done on every attributes; maybe some attributes are not
> searched by the spotlight menu, I don't know; what attribute do you
> miss? Display in the Spotlight window is limited by Apple's
> implementation.
You appear to be indexing:
kMDItemTitle
kMDItemAuthors
kMDItemAuthorEmailAddresses
kMDItemRecipients
kMDItemRecipientEmailAddresses
kMDItemContactKeywords
kMDItemContentCreationDate
kMDItemDisplayName
kMDItemTextContent
These are all *standard* attributes. I'm not belittling this. You
have one of only two clients on the platform that has *any* level of
Spotlight support. Good for you.
I was only thinking that since the messages in the PM DB are richer
in metadata than those in Mail, you could define some custom
attributes in your plugin. That would make it even better. I would
also prefer a different set of display attributes. The set of
attributes displayed for Mail's messages seems to be a better choice
than those for PM.
> Can you describe what you'd like to do that you can't with PowerMail's
> filters?
Yes, but its involved... so I've appended a rather long example below
[1]
[...]
>> - Security
>>
>> - built-in support for PGP or similar ?
>>
>
> Not in the short term.
Ack.
> I suppose that SpamSieve already handles ISP's spam headers, or can
> learn from them. However, you can use both "Spam headers" and "Another
> third party filter", and create a filter derived from the "SpamSieve -
> Evaluate" filter, but replacing:
> set spam rating of msg to externalSpamLevel
> by:
> set spam rating of msg to (spam rating of msg + externalSpamLevel)
Yes. Thanks. There are a number of possibilities here. I wasn't
meaning to be critical of PM here, more wondering why you don't allow
more than one of the options under:
Spam Filter Assistant -> Evaluate Spam:
to be selected by the user. This just seems like a nice possibility.
thanks for the info,
mark.
[1] consider this:
Inbox
Outbox
Gateway
Lists
Work
Personal
Official
etc.
as the upper level of the hierarchy for a folder-based filtering
system that could be used in Mailsmith. The gateway is a mailbox
through which pass all incoming and all outgoing messages which
receive any filtering. Two single fiarly simple filters can control
*all* of this flow (and thereby (if the app is appropriately
threaded) avoid delays caused by having to run loads of checks on
your incoming messages (in this localized example we assume its a
POP3 scenario and new messages arrive in Inbox).
One filter per "primarySort" mailbox (e.g. <Lists> from above) then
"pulls in" all relevant messages from the gateway. One beauty of this
is that you only need a single filter per "primary sort" and not two
(one for incoming and one for outgoing). You can also use very
general filters here e.g.:
IF <header text> contains <List-Id:>
deposit
which could pull *all* of your (properly formatted) list messages
into e.g "Lists".
But the *real* beauty of the system is that you haven't shot your
"filtering powder" yet. The show goes on, because you can have a
second layer of filters that take things further e.g.
Gateway
Lists
PowerMail Discussions
Mailsmith-talk
One simple filter can pull *all* relevant messages from <lists> into
e.g. <PowerMail Discussions>.
And it doesn't stop there. You could have:
Lists
PowerMail Discussions
PowerMail Discussions Harvest
PowerMail Discussions Archive 2004
PowerMail Discussions Archive 2003
PowerMail Discussions Info
Malsmith-talk
etc.
and the distributed filtering will automatically pull messages
further down here. You could, e.g. have a general filter of the form:
If <read> is equal to true
and <label> is equal to harvest
or <sender> is <self>
deposit
and you could attach this single filter to *all* of your myMailList
Harvest mailboxes and with a keystroke that sets a label, you have a
fully automated system for processing *all* of your list messages.
At the final levels (of this example hierarchy), you could have a
single script which sets a label that triggers a filter for the
archiving of messages from *all* of the <myList Harvest> mailboxes
into their appropriate archive mailboxes with e.g. an anual rollover.
In short, its a massively parallel extensible system for distributing
the filtering jobs throughout the hierarchy and enabling highly
automated processing at all levels of the hierarchy *rather* than
just a means of *transferring* messages in a single leap from Inbox
or Outbox to another single destination.
