Kevin Hunt wrote:
Hi Kevin,
Its great that you are interested in contributing. Here's some quick
feedback which I hope helps. Remember, its not my fetchmail stuff, its the
community's, and these are just the views of one member of that community.
> 1) Cron-scheduling in Steve Brewin's new fetchmail stuff. This way I
> can schedule fetchmail tasks to only run during business
> hours, MON-FRI.
<snipped>
I'm not sure why you wouldn't want to fetch mail outside of business hours,
but technically this is a good idea. Personally I would tag it so everything
was kept together like this...
<schedule>
<cron minute="13" hour="-1" month="-1" year="-1" day="-1"
isDayOfYear="false"/>
<cron minute="28" hour="-1" month="-1" year="-1" day="-1"
isDayOfYear="false"/>
<cron minute="43" hour="-1" month="-1" year="-1" day="-1"
isDayOfYear="false"/>
<cron minute="58" hour="-1" month="-1" year="-1" day="-1"
isDayOfYear="false"/>
</schedule>
...and while I can't see why you would want to, there is no technical reason
why <schedule> and <interval> need to be mutually exclusive. Only one fetch
task will run at a time, if a fetch is triggered while one is running its
ignored.
> 2) FetchMail search terms.
<snipped>
> <fetchfilter> would effectively obsolete the <fetchall> option.
Not without provision for changing the mail state to delete of seen,
otherwise there is no way to avoid processesing the same messages over and
over.
<snipped>
> <!-- <receiveddate comparison="GT/GE/LT/LE/EQ/NE"
date="Simple date"> -->
> <!-- <sentdate comparison="GT/GE/LT/LE/EQ/NE" date="Simple
date"> -->
In most use-cases, wouldn't "Simple date" need to be dynamic or expressed as
an offset such as 30 days ago?
<snipped>
> <!-- <messageid id="RFC822 message id"> -->
> <!-- <messagenumber number="message number"> -->
How do you know the messageid and number beforehand to match on it?
<snipped>
My rational for including some simple filters to fetchmail were:
1) To avoid injecting mail into James that had been willfully (or
accidentally) sent to the ISP hosting the mail server in the hope of it
getting picked up by a mail client or relayed.
2) To handle situations unique to messages fetched from a message store,
such as being unable to identify the intended recipient.
3) To avoid the cost of fetching the message bodies for mail that is going
to be rejected.
Personally, I feel that generalised mail processing of the type you propose
should be left to James' mailet chain. Otherwise, where do you stop? Before
we know it, someone will realise that however many filters we add, there is
always a new requirement and propose that we add a pluggable message
processing structure into fetchmail, ie: mailets! As we already have this in
James we don't need it elsewhere.
Many of the criteria you specify would equally apply to mail injected from
all sources, not just fetchmail, so its best to define it just once, in
James' mailet chain.
As touched on in (3) above, fetchmail is written to avoid the overhead of
touching the message body. In fact, next up in my to do list is to switch to
using an InputStream when the message delivered into James is created so
that we don't EVER touch the message body in fetchmail. This will be
defeated if we start checking the contents or size of the message body.
As you have probably gathered, I'm personally not taken by the idea of
adding this to fetchmail. It would make a useful matcher though.
> This sort of SearchTerm stuff is extremely flexible, and this
> could be
> easily adapted to a Matcher if the mailet spec changes to
> allow Matcher
> configuration of more than just a String -- which I hope is
> still being
> considered.
It is already possible to pass search terms such as this to a matcher, if
somewhat cumbersome. The scripting support added by ScriptedMatcher does
this. Unfortunately, it hasn't made its way into head yet, but I would be
happy to send you the code to examine.
> 3) "Restart on config change" feature.
<snipped>
If JMX is enabled, you can use a JMX console to restart James. You should
also be able to progammatically ask Phoenix to restart James directly or via
JMX, but I haven't done so.
> Lastly, I'm a bit naive when it comes to CVS and creating diffs for
> patches.
<snipped>
I develop in Eclipse and use its Patch creation facility. This works well
except for a bug when including new files in new directories in the patch
(so don't). Be sure to configure the Eclipse editors to use spaces instead
of tabs and Unix line delimiters. You might want to post this, and the
restart question seperately so you get the views of others who have no
interest in fetchmail.
I hope this helps.
Cheers,
-- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
