the incoming.pl script is what actually 'delivers' the mail to the various users. Many ISP's batch the mail, and AOL varies from almost immediate send, to 15 minutes (occasionally more) delay. This is why your ISP may tell you that mail sent to you is not immediately available, even if the site that sent it to you tells you it was already sent (you've seen this, and maybe hit this).
Ok, so much for the background.
How often you run the incoming.pl script will be the 'delay' in delivering the mail you add to your ISP's delay in delivering the mail your main catchall account.
If you have a light-load on your system, and you want to give your users speedy performance, you could probably run the incoming.pl script every 2-5 minutes without doing much damage.
But, if you are running a heavy loaded server, with a lot of mail activity, it's probably better to extend that to at least 10-15 minutes to give the program more running time before restarting.
Think about driving -- and hitting a stoplight that turns red too fast for the amount of traffic waiting in the turn lane. Things back up really fast, but if the light stayed green for only a few more seconds, more cars would have been able to go through without the 'start up' penalty. Make sense?
If you have a lot of mail coming into the system, it's better to run a program _less_ frequently, but for longer periods, than it is to start/stop it very often. It's possible if you were running the script too often on a heavily loaded system, you'd start running multiple instances of the script, and slowing things down more......
Now, I'm sure Alex can give more details on this, and maybe I'm completely off base with how Gossamer Mail is working (I'm still working to understand it), but the assumptions above work for standard mail delivery and cron jobs, so it should apply to GossMail as well.
I'm hoping to dive deeper into this once the new release of Links SQL comes out, since my goal will be to work on getting all the programs (and a few others) to work together with the same user base, user data, etc across the site (or even multiple related sites). Until such time, I'm sill in almost as much of a fog as everyone else on getting this program up, running, fine-tuned, and humming like well oiled machine :)
But, I would like the ability of a shared user registration across a network of linked sites, access to mail, links, ratings, shopping, preferences, etc.
I want to offer user convenience accross related offerings (either from the same parent company, or from an affiliated network of sites) that let the user remember one password and have one centrally updated "profile" but allow them to wander through the 'network' as a recognized user. This gives the webmaster (and the user) many benefits -- such as higher-status, better targeting, targeted discounts, etc.
I know this will apply to "adult" sites (they are already chomping at the bits for this) but it will also help targeted links sites, catalog sites, and others that want to share traffic, create partnerships, and forge alliances to compete with the 'big guys.'
Nothing prevents a user from registering separately on each site, but they have the option of registering once, and using the same shared registry.
A business can set up their own shared registry for all their sites, or a 3rd party can set up a shared registry for member sites. That way no one site has control over the data, or unfair use of it.
Cool... huh?? :)
a mini-Amazon.
http://www.postcards.com FAQ:
http://www.postcards.com/FAQ/LinkSQL/