However, the contents of the HDR file are retained in memory by SmarterMail.
That sounds like it could lead to a memory leak. I tried SM as a SmartHost caching server and deleted all returns beforee SM could send them. About once a week I had to reboot the machine. Now I think I know why.
-d
----- Original Message ----- From: "David Franco-Rocha [ Declude ]" <[EMAIL PROTECTED]>
To: <Declude.JunkMail@declude.com>
Sent: Monday, May 02, 2005 8:27 AM
Subject: Re: Re[6]: [Declude.JunkMail] Imail 8.2 / smartermail
See below.
David Franco-Rocha
----- Original Message ----- From: "David Sullivan" <[EMAIL PROTECTED]>
To: <Declude.JunkMail@declude.com>
Sent: Friday, April 29, 2005 5:28 PM
Subject: Re[6]: [Declude.JunkMail] Imail 8.2 / smartermail
Hello David,
Friday, April 29, 2005, 4:55:53 PM, you wrote:
DFRD> No, there is not an inherent delay in the delivery of all messages. If
DFRD> Declude does not complete processing within a specified time period,
DFRD> SmarterMail tries to take the file. However, if Declude finishes processing
So, does this mean that SM could process a file that Declude did NOT scan?
That should not happen, since the message is passed to Declude by SmarterMail.
Or, are you saying this moving the file in a different folder process prevents SM from EVER processing a file that Declude hasn't finished?
No, I am not saying that at all. There are some unique aspects regarding the way SmarterMail processes messages that necessitate equally unique behavior on the part of Declude (unfortunately). When the incoming SMTP dialogue has been completed, SmarterMail creates the envelope file (HDR) and the message data file (EML). However, the contents of the HDR file are retained in memory by SmarterMail. The most significant negative effect of this behavior is that changes made by Declude to the envelope (re-routing a recipient, deleting a recipient, etc.) are not seen by SmarterMail; when SmarterMail regains control of the message it uses the envelope in memory and completely disregards any changes made to the envelope.
To circumvent this behavior, Declude renames the HDR and EML files after processing by prepending X to the spool name prior to moving the message back to the SmarterMail spool. This causes SmarterMail to see this as a new message and reads a new envelope into memory. It eventually realizes that, in a sense, the old message has been deleted. Since this is seen as a new message by SmarterMail, it tries to pass it once again to Declude. However, Declude ignores all messages whose names begin with X because it knows they have already been processed.
DF
-- Best regards, David mailto:[EMAIL PROTECTED]
--- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
--- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
--- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
