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, Davidmailto:[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.
[Declude.JunkMail] OT: AOL Treats FL Emergency response as spam.
Its OT, but its funny.. AOL rocks. http://news.yahoo.com/news?tmpl=storyu=/ap/20050502/ap_on_hi_te/emergency_spam
RE: [Declude.JunkMail] OT: AOL Treats FL Emergency response as spam.
Title: Message Its OT, but its funny.. AOL rocks. Not so funny for those of us that live in FL! :)
RE: [Declude.JunkMail] OT: AOL Treats FL Emergency response as spam.
Youcan't realistically blame AOL here. Anyone using an AOL account for this kind of application is making a serious error in judgement. Why aren't they partnering with FEMA or running their own server? The only reason I can imagine them using AOL is ... and this is a struggle ... for offsite protection. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William StillwellSent: Monday, May 02, 2005 9:41 AMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] OT: AOL Treats FL Emergency response as spam. Its OT, but its funny.. AOL rocks. http://news.yahoo.com/news?tmpl=storyu=/ap/20050502/ap_on_hi_te/emergency_spam
RE: [Declude.JunkMail] OT: AOL Treats FL Emergency response as spam.
Uh, I understood it to be that some "recipients" were on AOL - not the sender! It's also not AOLs fault, if some AOL customers have blocked the receipt because they are too lazy to unsubscribe. And, AOL does have means to allow certain senders to be "white-listed". I think it's more a matter ofFL going to the press instead of going to someone who understands SMTP. Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean FaheySent: Monday, May 02, 2005 11:03 AMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] OT: AOL Treats FL Emergency response as spam. Youcan't realistically blame AOL here. Anyone using an AOL account for this kind of application is making a serious error in judgement. Why aren't they partnering with FEMA or running their own server? The only reason I can imagine them using AOL is ... and this is a struggle ... for offsite protection. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William StillwellSent: Monday, May 02, 2005 9:41 AMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] OT: AOL Treats FL Emergency response as spam. Its OT, but its funny.. AOL rocks. http://news.yahoo.com/news?tmpl=storyu=/ap/20050502/ap_on_hi_te/emergency_spam
RE: [Declude.JunkMail] OT: AOL Treats FL Emergency response as spam.
My mistake. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy SchmidtSent: Monday, May 02, 2005 10:15 AMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] OT: AOL Treats FL Emergency response as spam. Uh, I understood it to be that some "recipients" were on AOL - not the sender! It's also not AOLs fault, if some AOL customers have blocked the receipt because they are too lazy to unsubscribe. And, AOL does have means to allow certain senders to be "white-listed". I think it's more a matter ofFL going to the press instead of going to someone who understands SMTP. Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean FaheySent: Monday, May 02, 2005 11:03 AMTo: Declude.JunkMail@declude.comSubject: RE: [Declude.JunkMail] OT: AOL Treats FL Emergency response as spam. Youcan't realistically blame AOL here. Anyone using an AOL account for this kind of application is making a serious error in judgement. Why aren't they partnering with FEMA or running their own server? The only reason I can imagine them using AOL is ... and this is a struggle ... for offsite protection. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William StillwellSent: Monday, May 02, 2005 9:41 AMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] OT: AOL Treats FL Emergency response as spam. Its OT, but its funny.. AOL rocks. http://news.yahoo.com/news?tmpl=storyu=/ap/20050502/ap_on_hi_te/emergency_spam
Re: Re[6]: [Declude.JunkMail] Imail 8.2 / smartermail
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, Davidmailto:[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.
