A reminder that processing the list mail immediately has the problem of
potentially timing out the client who is sending the mail, which then
requeues it for sending a few minutes later. That discovery was one of my
more painful experiences, as 17,000 people received multiple messages, and
bombarded me with "Stop sending me all these messages".
I image you can code it so that the connection with the client closes once
the mail is received but before the messages are generated and queued up in
/OUT. My current design immediately archives the mail, setting a flag to
"Undelivered", and then sends a confirmation to the send indicating that
their mail has been queued. Another process (a simple perl script), calls
something to check the queue every few minutes and generates the mail.
Tac
----- Original Message -----
From: "Howie Hamlin" <[EMAIL PROTECTED]>
To: "inFusion Support List" <[EMAIL PROTECTED]>
Sent: Tuesday, September 12, 2000 9:25 AM
Subject: Re: [iMS] 'internal' email
>
> ----- Original Message -----
> From: "Tac/Smokescreen Action Network" <[EMAIL PROTECTED]>
> To: "inFusion Support List" <[EMAIL PROTECTED]>
> Sent: Monday, September 11, 2000 9:44 AM
> Subject: Re: [iMS] 'internal' email
>
>
> > Fabulous! This will particularly help those of us that are handling
> errors
> > by directing them to specialized local accounts. Right now, they go
into
> to
> > post queue and are resent to SMTP, and when there are hundreds or
> thousands
> > of errors (like when sending a newsletter with addresses that haven't
been
> > cleaned in a while), this can cause the POST server to slow to a crawl.
> >
>
> Yes, this is a limitation of the current version of FusionMail...it
blindly
> uses the POST Server even for local mail. When FusionMail was released we
> designed it as a demo. Unfortunately for us FusionMail has taken on a
more
> significant role.
>
> > For many of us, FusionMail will be the base and we'll just tweak it to
> take
> > advantage of the iMS flexibility. But yes, FusionMail has a life of its
> > own!
> >
>
> Yes, this has happened much to our chagrin...
>
> Regards,
>
> Howie
>
> > Tac
> >
> > PS Any chance the listserv integration will be ready for testing this
> week?
> >
>
> It's possible...but no promises. Right now we have some new stuff in
> place - like a custom tag that does verification of local addresses and
> another custom tag that does DB insertions for local accounts. These are
> working quite well and just need to be integrated into the RCPT and DATA
> templates. After that we'll code the list server stuff. The initial list
> server stuff will be coded so that the mail is processed immediately. In
> the future I think it would be better to simply write a DB record for a
> scheduled process to pick up and process. The initial list server will
> include discussion and announcement/newsletter list but will not include a
> digest for the discussion list. This new version of FusionMail will be
> version 2.0 (thus orphaning version 1.1).
>
>
>
>
> ========================================================================
> This list server is Powered by iMS
> 'The Swiss Army Knife of Mail Servers'
> --------------------------------------
> To leave this list please complete the form at
> http://www.CoolFusion.com/iMS.htm
>
> List archives: http://www.mail-archive.com/infusion-email%40eoscape.com/
> ========================================================================
>
========================================================================
This list server is Powered by iMS
'The Swiss Army Knife of Mail Servers'
--------------------------------------
To leave this list please complete the form at
http://www.CoolFusion.com/iMS.htm
List archives: http://www.mail-archive.com/infusion-email%40eoscape.com/
========================================================================
