----- Original Message -----
From: Tac/Smokescreen Action Network <[EMAIL PROTECTED]>
To: inFusion Support List <[EMAIL PROTECTED]>
Sent: Saturday, May 06, 2000 1:40 PM
Subject: Re: [iMS] Log files
> I've been using a utility with NTMail that has been invaluable for
> monitoring the NTMail threads. It's quite a clever interface for
monitoring
> a multi-threaded process. NTMail writes debug lines to port 22000, this
> utility reads it and splits up the threads, and concatented the results
into
> a window as well. It's likely that you'd be able to use the utility as
> well, but I'm not sure.
>
> http://ftp.leftcoast.net/pub/ntmail/utils/
>
I'm not sure of the legal ramifications (if any) of making iMS compatible
with that utility. I'm familiar with it and I know what it does but...
> >
> > And then send the mail from a special address like:
> > [EMAIL PROTECTED]
>
> This would work well for a probe e-mail, sent out to list members to
confirm
> that the address is valid. But I'd also like to handle the case where the
> mail gets bounced back and I want to do something with it -- take it out
of
> the queue, leave it there, mark the offending address, etc. This would be
a
> very cool and unique feature for the FusionMail web interface for the POP
> accounts. Imagine popping up your address book and seeing stats on what
> e-mail address is no longer valid!
>
I thinnk it's OK to use that setup for regular list mail as well as
probes...remember, the list members would still reply to the list if the
Reply-to header specified the list address. What I was talking about was
that the iMS server would say:
MAIL FROM: [EMAIL PROTECTED]
And then the remote mail server would use that address to send failure
notifications...
> >
> > c:\ims\logs is the log directory. If there is a file called CYCLEPOST
in
> > there then the POST server would:
> >
> > 1 - close and rename the current log file (to POSTxxxxxx.log to
> > POSTxxxxxx.001 for example)
> > 2 - create a new log file
> > 3 - delete the CYCLEPOST file
> >
> > Would that work for you?
>
> Yes. Having it available as a button from the Configurator would be
great,
> too, although I definitely like the idea of being able to cycle it from an
> external program simply by creating the CYCLEPOST file.
>
OK...I can have that functionality added...
> >
> > > Second, is there a way to control the log file output, or to
manipulate
> > > anything along the way? For example, I'd like to see the recipient
> > address
> > > in the log, along with the "to" address, the sender address, etc,
along
> > with
> > > any error messages.
> > >
> >
> > That would add to the size of the log file. There are entries that have
> the
> > information in them with the thread ID. I guess that could be an
optional
> > setting. This is the POST log we're talking about, right
>
> POST and SMTP. Right now, a snippet of the POST file looks like
>
> 08:14:31 AM DEBUG [001] <-250 Requested mail action Ok.
> 08:14:31 AM [001] AE0421F64523D411967900105AE2E92D.mbx sent successfully
to
> [EMAIL PROTECTED]
> 08:14:31 AM DEBUG [001] ->quit
> 08:14:32 AM DEBUG [003] <-250 Requested mail action Ok.
>
> I'd like to be able to set someone, preferably in DATA template, something
> that allows me to print out to the log file the data I have, e.g.
>
> #Now()# #Form.filename# sent from #STMPFrom# to #SMTPTo#
>
Hmmm...that's an interesting idea...sort of like:
<inLog #Now()# #Form.filename# sent from #STMPFrom# to #SMTPTo#>
> I imaging that right now the engine calls the templates and looks for
> strings such as "result=accept" or "result=mailbox_full" or whatever. For
> these more generic log lines, you'd probably want to it accepts something
> like "<LOG>Error: Invalid List name: #Listname#</LOG>" I thought I
remember
> seeing a call about writing something to the log file, but can't find it
> now.
>
There is no way presently for you to write to the iMS log files but I do see
some value in that...
> Just some thoughts. I do find debugging quite difficult because you have
to
> change the processing templates, send an e-mail, wait a little bit, then
> check the log files to see if you've made any syntax errors. I keep
> planning to build a debug system that's web-based rather than iMS-based,
> just for that reason, but...
>
Well, a few things:
1 - All CF errors are written to the log files so you can see them
2 - We provide a test suite so that you can test each server
3 - We provide free developer licenses for testing
> > the user is unknown. You would like the POST server to call a template,
> > called DELIVERYERROR for example, and then supply the sender, recipient
> and
> > the error (transient or permanent)?
>
> YES, sender, recipient, filename (the template could then process it for
> headers, etc.)
>
> Thanks for considering my suggestions!
>
No problem...I'll see how quickly we could get these things implemented...
Howie
> Tac
>
>
>
> ========================================================================
> This list server is Power 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 Power 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/
========================================================================
