Re: [Declude.JunkMail] Win a FREE Copy of ?
Very frankly, I'm not in favor of a new name since the product will remain the same. As others have already recognized and evaluated, Version 4 should really be called the Declude Suite. All new sales will be of the Declude Suite which contains all the current products while current users may continue to license individual portions as they do now. I think Declude should be able to accomplish via the use of the current licensing scheme, i.e., individual parts activated by a license code in config files. Like many others here, I cannot fathom how you would accomplish a licensing scheme where a product would fail to operate when a license expires. The only way I know to effect this is to have a product periodically "call home". This is antsy at best with network problems, firewalls, test servers not really in full service, and (God forbid) a company goes belly up and the servers are taken off-line. Even though we were either the very first or maybe the 2nd National Bank to be an ISP (way back in '96), we're now part of a dying breed because we cannot offer a broadband connection Consequently, I have to watch the costs carefully or my job will also be extinct. With this being said, I too, have stayed with Version 1.82 and IMail 8.x simply because we do not have the personnel, hardware or time to chase the many problems which have been a great part of this list. I simply cannot justify suffering the headaches when so little additional functionality is being provided. In that, I am very disappointed. So my vote for a name is Declude Suite (Version 3) and further identified by a Build number. ~Joe - Original Message - From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> To: Sent: Tuesday, February 14, 2006 11:55 AM Subject: [Declude.JunkMail] Win a FREE Copy of ? Okay, it's time for all of us at Declude to face the facts: naming products is not our strength and naming our latest release Version 4 showed both a lack of imagination and an ability to cause confusion. After all, we wouldn't name our latest child Version 2! At least most of us wouldn't Realizing that we are pretty good at designing software and pretty bad at naming it, we thought we would let you have a go at naming this latest release. Please, nothing provocative or off-color, unless it's particularly good. In any case, don't be afraid to let imagination run rampant. We need your suggestions no later than 5pm Eastern Time on Wednesday, February 15th. At that point we will have a run off vote that will end this Friday, February 17th. The winning name will receive a free copy of ? (Currently known as Version 4) and a free one year service agreement on your current software. All names should be submitted by email to [EMAIL PROTECTED] The back of napkins, prescription pads, Dunkin' Donuts cups, bar coasters and Subway sandwich wraps will not be accepted as valid entries. All employees of Declude and their families are ineligible. Good luck! --- [This E-mail was scanned for viruses by Declude EVA www.declude.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 scanned for viruses at HNB.com] --- [This E-mail was scanned for viruses by Declude EVA www.declude.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.
RE: [Declude.JunkMail] Filter question
Thanks Matt. John T eServices For You "Seek, and ye shall find!" -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Tuesday, February 14, 2006 3:46 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Filter question Move the whitelist setting to a custom filter and place an END on the filter for the condition that you want to track elsewhere: MAILFROM END IS [EMAIL PROTECTED] REMOTEIP WHITELIST IS 12.34.56.78 Have a good evening, Matt John T (Lists) wrote: I need to create a filter for a client that I am gatewaying their Exchange server. I have their server listed in the Global.cfg for whitelisting. (WHITELIST IP yaddayaddayadda) Now there is a need to create a filter file so that if the e-mail is from a broadcast address and to an address on the list, to route to back to the sales manager. -- MAILFROM END NOTCONTAINS [EMAIL PROTECTED] ALLRECIPS 0 CONTAINS e-mailaddresslisted -- On Failure, route to [EMAIL PROTECTED] Is there a way to override a whitelist? John T eServices For You "Seek, and ye shall find!"
Re: [Declude.JunkMail] Filter question
Move the whitelist setting to a custom filter and place an END on the filter for the condition that you want to track elsewhere: MAILFROM END IS [EMAIL PROTECTED] REMOTEIP WHITELIST IS 12.34.56.78 Have a good evening, Matt John T (Lists) wrote: I need to create a filter for a client that I am gatewaying their Exchange server. I have their server listed in the Global.cfg for whitelisting. (WHITELIST IP yaddayaddayadda) Now there is a need to create a filter file so that if the e-mail is from a broadcast address and to an address on the list, to route to back to the sales manager. -- MAILFROM END NOTCONTAINS [EMAIL PROTECTED] ALLRECIPS 0 CONTAINS e-mailaddresslisted -- On Failure, route to [EMAIL PROTECTED] Is there a way to override a whitelist? John T eServices For You "Seek, and ye shall find!"
[Declude.JunkMail] Filter question
I need to create a filter for a client that I am gatewaying their Exchange server. I have their server listed in the Global.cfg for whitelisting. (WHITELIST IP yaddayaddayadda) Now there is a need to create a filter file so that if the e-mail is from a broadcast address and to an address on the list, to route to back to the sales manager. -- MAILFROM END NOTCONTAINS [EMAIL PROTECTED] ALLRECIPS 0 CONTAINS e-mailaddresslisted -- On Failure, route to [EMAIL PROTECTED] Is there a way to override a whitelist? John T eServices For You "Seek, and ye shall find!"
Re: [Declude.JunkMail] Win a FREE Copy of ?
This one is for free. When some of the original people from WebTrends took the company back over from NetIQ after they priced themselves out of the market, they decided to follow up the 8.x release with the 7.x release even though there was previously a 7.x release that was completely different. I think this was supposed to be a reflection of throwing out what NetIQ had done to the code, but it took me about an hour to figure out what was going on. I hear they are working hard on 6.x right now :) Matt [EMAIL PROTECTED] wrote: Okay, it's time for all of us at Declude to face the facts: naming products is not our strength and naming our latest release Version 4 showed both a lack of imagination and an ability to cause confusion. After all, we wouldn't name our latest child Version 2! At least most of us wouldn't Realizing that we are pretty good at designing software and pretty bad at naming it, we thought we would let you have a go at naming this latest release. Please, nothing provocative or off-color, unless it's particularly good. In any case, don't be afraid to let imagination run rampant. We need your suggestions no later than 5pm Eastern Time on Wednesday, February 15th. At that point we will have a run off vote that will end this Friday, February 17th. The winning name will receive a free copy of ? (Currently known as Version 4) and a free one year service agreement on your current software. All names should be submitted by email to [EMAIL PROTECTED] The back of napkins, prescription pads, Dunkin' Donuts cups, bar coasters and Subway sandwich wraps will not be accepted as valid entries. All employees of Declude and their families are ineligible. Good luck! --- [This E-mail was scanned for viruses by Declude EVA www.declude.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 was scanned for viruses by Declude EVA www.declude.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.
Re: [Declude.JunkMail] large mail to large number op recips
I suppose then it is fixed. Broken somewhere in 2.x and fixed somewhere in 3.x. There are no release notes mentioning having fixed this however. This fix is something that I desired and would help to compel me to move to 3.x. Matt Scott Fisher wrote: I didn't check that. I just spot checked two emails and I could find no reference to them in any of my external program logs. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 12:56 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips Did you check the logging of your external tests to make sure? I generally find no log lines in the JunkMail logs for tests that failed, or maybe just something like the LEGITCONTENT test, but the external tests' logs show that they were in fact run for everything besides WHITELIST AUTH. Matt Scott Fisher wrote: In 3.x WHITELIST IP does skip the tests. I have very rare occurances (10 this month) where some WHITELIST AUTH do have tests run but the weight is set to 0. (3.0.5.23) - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 12:07 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips PREWHITELIST ON isn't working completely anyway, at least in 2.x. I would like to have it fixed though. Here's an example: WHITELIST AUTH still skips tests with PREWHITELIST ON, but using actions in your global.cfg like WHITELIST IP or WHITELIST SUBJECT will result in tests being run. This used to not be the case. It will whitelist the message though, it just won't skip running the tests. Maybe it was fixed in a 3.x release, but I haven't seen any mentions of it being addressed. Matt Scott Fisher wrote: E... that'll popup the CPU time. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:29 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips I just want to help prevent confusion here, and I'm thinking that you might not be all the way up the thread yet. You are of course correct on how to do this with Declude Pro 2.0.6.16 so long as the users aren't whitelisted. I suspect that they are however since they are internal and that is generally considered to be a best practice, and if they are, they either need to turn off whitelisting (which might not be preferable), or use another method such as have the script modify the E-mail's D* file while setting PREWHITELIST OFF in order to ensure that such scripts are run. Matt Scott Fisher wrote: If they were BCCs... You could set a BCC threshold using the internal Declude bcc test BCC-50 bcc 10 x 10 0 also run a size test: SIZE-GT-1MB external 18 "D:\vb\Size.exe PATH=d:\vb\ LOGLEVEL=ERRORSONLY SZ=5,1000,5000,1,10,20,50,100" 0 0 Then have a combo filter TESTSFAILED END NOTCONTAINS BCC-50 TESTSFAILED 0 CONTAINS SIZE-GT-1MB so every email with 50 bcc's and >1 MB would trigger the filter. If they aren't bcc's, then you are into vba land. a link to Matt's vbs is here. I compiled it into a exe. that link is there too. http://it.farmprogress.com/declude\declude.htm - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 10:29 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips See Matt's reply. IIRC, both he and Scott Fisher had variants on the size test, one was _vbscript_ and the other was an EXE. You might check's Scott's website as he had compiled a list of tools and scripts he uses. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:18 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi,
Re: [Declude.JunkMail] large mail to large number op recips
I didn't check that. I just spot checked two emails and I could find no reference to them in any of my external program logs. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 12:56 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips Did you check the logging of your external tests to make sure? I generally find no log lines in the JunkMail logs for tests that failed, or maybe just something like the LEGITCONTENT test, but the external tests' logs show that they were in fact run for everything besides WHITELIST AUTH.MattScott Fisher wrote: In 3.x WHITELIST IP does skip the tests. I have very rare occurances (10 this month) where some WHITELIST AUTH do have tests run but the weight is set to 0. (3.0.5.23) - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 12:07 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips PREWHITELIST ON isn't working completely anyway, at least in 2.x. I would like to have it fixed though. Here's an example:WHITELIST AUTH still skips tests with PREWHITELIST ON, but using actions in your global.cfg like WHITELIST IP or WHITELIST SUBJECT will result in tests being run. This used to not be the case. It will whitelist the message though, it just won't skip running the tests. Maybe it was fixed in a 3.x release, but I haven't seen any mentions of it being addressed.MattScott Fisher wrote: E... that'll popup the CPU time. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:29 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips I just want to help prevent confusion here, and I'm thinking that you might not be all the way up the thread yet. You are of course correct on how to do this with Declude Pro 2.0.6.16 so long as the users aren't whitelisted. I suspect that they are however since they are internal and that is generally considered to be a best practice, and if they are, they either need to turn off whitelisting (which might not be preferable), or use another method such as have the script modify the E-mail's D* file while setting PREWHITELIST OFF in order to ensure that such scripts are run.MattScott Fisher wrote: If they were BCCs... You could set a BCC threshold using the internal Declude bcc test BCC-50 bcc 10 x 10 0 also run a size test: SIZE-GT-1MB external 18 "D:\vb\Size.exe PATH=d:\vb\ LOGLEVEL=ERRORSONLY SZ=5,1000,5000,1,10,20,50,100" 0 0 Then have a combo filter TESTSFAILED END NOTCONTAINS BCC-50 TESTSFAILED 0 CONTAINS SIZE-GT-1MB so every email with 50 bcc's and >1 MB would trigger the filter. If they aren't bcc's, then you are into vba land. a link to Matt's vbs is here. I compiled it into a exe. that link is there too. http://it.farmprogress.com/declude\declude.htm - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 10:29 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips See Matt's reply. IIRC, both he and Scott Fisher had variants on the size test, one was _vbscript_ and the other was an EXE. You might check's Scott's website as he had compiled a list of tools and scripts he uses. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:18 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Indeed that is what I want, to catch the exceptions. So WHO has the too
RE: [Declude.JunkMail] large mail to large number op recips
I agree it would not solve the problem, it is a good first step and will make his server more reliable in that it will not run out of disk space if it does happen. Allowing larger attachments is just ignorance or stupidity. I would like to think ignorance, not necessarily on Bonno's part but on whomever makes the final decisions on these maters, not always the mail admin. Users will try to get all they can when it comes to attachemnts. As an mail server administrator you must weigh the reliability of the system against the users wants, not to be confused with needs, and the reliability/stability of the system. Kevin Bilbee -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Darin CoxSent: Tuesday, February 14, 2006 11:26 AMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] large mail to large number op recips Limiting attachment size wouldn't solve the problem unless the number of recipients is also limited. While I agree with you on the 10MB limit (that's what we use as a limit), in his case, it's the combo that's the problem, not the single message. From what I read, he wants to allow larger attachments, but have a safeguard if that attachment is going to too many recipients. Darin. - Original Message - From: Kevin Bilbee To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 2:05 PM Subject: RE: [Declude.JunkMail] large mail to large number op recips Yes, I realize that. But limiting attachemnt size is a way to avoid this problem in the future. Having a file size limit would have stoped this in its tracks. Also a file size limit will get users thinking of more efficient ways to transfer files. Thus avoiding crashing the server. Imagine if the 33mb email went to the 1,500 addresse list it would have killed his server he sould not have any disk space left. Kevin Bilbee -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Darin CoxSent: Tuesday, February 14, 2006 10:19 AMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] large mail to large number op recips Hi Kevin, I think the point Bonno was making was that it was the combination of file size AND number of recipients that was the problem. He probably has a file size limit in place, but when a 10MB attachment goes to 100 people, you're suddenly at 1.2-1.4 GB of disk space used. Yes, he could limit number of recipients as well, but that would unnecessarily limit other broadcast messages on his network. I think we all understand the education issue, but also know we have to take steps to protect ourselves against users who forget, don't realize, or just plain ignore the policies we put in place. Darin. - Original Message - From: Kevin Bilbee To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 1:06 PM Subject: RE: [Declude.JunkMail] large mail to large number op recips I realize this was an accident mailing but you should have in place attachment size limits to avoid sucking the disk space of the mail server and to avoit filling up mailboxes to unrealistic sizes. On average an attachment will become 20% larger once encoded in an email. Users should know a 10mb file attachment will take up about 12mb of mailbox space and will be viewed as a 12mb attachement. I would limit the size of attachments to no more that 10mb in the mail server to start. Then I would setup an upload/download for files larger than 10mb. Educate your users on how sending large files can cause all kinds of problems. Like send/receive timing out and resetting, resulting in dulpicate mssages being downloaded. I get calls all the time to delete large messages from mail boxes on domains that pay to not have a file size attachemnt limit. Kevin Bilbee -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Darin CoxSent: Tuesday, February 14, 2006 6:31 AMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the
Re: [Declude.JunkMail] large mail to large number op recips
Limiting attachment size wouldn't solve the problem unless the number of recipients is also limited. While I agree with you on the 10MB limit (that's what we use as a limit), in his case, it's the combo that's the problem, not the single message. From what I read, he wants to allow larger attachments, but have a safeguard if that attachment is going to too many recipients. Darin. - Original Message - From: Kevin Bilbee To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 2:05 PM Subject: RE: [Declude.JunkMail] large mail to large number op recips Yes, I realize that. But limiting attachemnt size is a way to avoid this problem in the future. Having a file size limit would have stoped this in its tracks. Also a file size limit will get users thinking of more efficient ways to transfer files. Thus avoiding crashing the server. Imagine if the 33mb email went to the 1,500 addresse list it would have killed his server he sould not have any disk space left. Kevin Bilbee -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Darin CoxSent: Tuesday, February 14, 2006 10:19 AMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] large mail to large number op recips Hi Kevin, I think the point Bonno was making was that it was the combination of file size AND number of recipients that was the problem. He probably has a file size limit in place, but when a 10MB attachment goes to 100 people, you're suddenly at 1.2-1.4 GB of disk space used. Yes, he could limit number of recipients as well, but that would unnecessarily limit other broadcast messages on his network. I think we all understand the education issue, but also know we have to take steps to protect ourselves against users who forget, don't realize, or just plain ignore the policies we put in place. Darin. - Original Message - From: Kevin Bilbee To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 1:06 PM Subject: RE: [Declude.JunkMail] large mail to large number op recips I realize this was an accident mailing but you should have in place attachment size limits to avoid sucking the disk space of the mail server and to avoit filling up mailboxes to unrealistic sizes. On average an attachment will become 20% larger once encoded in an email. Users should know a 10mb file attachment will take up about 12mb of mailbox space and will be viewed as a 12mb attachement. I would limit the size of attachments to no more that 10mb in the mail server to start. Then I would setup an upload/download for files larger than 10mb. Educate your users on how sending large files can cause all kinds of problems. Like send/receive timing out and resetting, resulting in dulpicate mssages being downloaded. I get calls all the time to delete large messages from mail boxes on domains that pay to not have a file size attachemnt limit. Kevin Bilbee -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Darin CoxSent: Tuesday, February 14, 2006 6:31 AMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 8:51 AM Subject: [Declude.JunkMail] large mail to large number op recips Hi, We are a school and: - sometimes someone needs to send a large e-mail (20-30 MB) to one of the staf or students. - several times a day we send e-mails to large groups of students so the BCC field might contain up to 1500 addresses. Both items are no problem until they are combined like some tried today. :-( Suddenly I lost around 15GB of diskspace on my mailserver. At least that is what IMail tried because I only had about 10GB left on my mailbox drive. Guess what happened? Is there a way using Declude Junkmail to flag this situation and stopping the e-mail while still allowing the two items above? I'm currently using Declude 2.16, Junkmail Std
RE: [Declude.JunkMail] large mail to large number op recips
Yes, I realize that. But limiting attachemnt size is a way to avoid this problem in the future. Having a file size limit would have stoped this in its tracks. Also a file size limit will get users thinking of more efficient ways to transfer files. Thus avoiding crashing the server. Imagine if the 33mb email went to the 1,500 addresse list it would have killed his server he sould not have any disk space left. Kevin Bilbee -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Darin CoxSent: Tuesday, February 14, 2006 10:19 AMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] large mail to large number op recips Hi Kevin, I think the point Bonno was making was that it was the combination of file size AND number of recipients that was the problem. He probably has a file size limit in place, but when a 10MB attachment goes to 100 people, you're suddenly at 1.2-1.4 GB of disk space used. Yes, he could limit number of recipients as well, but that would unnecessarily limit other broadcast messages on his network. I think we all understand the education issue, but also know we have to take steps to protect ourselves against users who forget, don't realize, or just plain ignore the policies we put in place. Darin. - Original Message - From: Kevin Bilbee To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 1:06 PM Subject: RE: [Declude.JunkMail] large mail to large number op recips I realize this was an accident mailing but you should have in place attachment size limits to avoid sucking the disk space of the mail server and to avoit filling up mailboxes to unrealistic sizes. On average an attachment will become 20% larger once encoded in an email. Users should know a 10mb file attachment will take up about 12mb of mailbox space and will be viewed as a 12mb attachement. I would limit the size of attachments to no more that 10mb in the mail server to start. Then I would setup an upload/download for files larger than 10mb. Educate your users on how sending large files can cause all kinds of problems. Like send/receive timing out and resetting, resulting in dulpicate mssages being downloaded. I get calls all the time to delete large messages from mail boxes on domains that pay to not have a file size attachemnt limit. Kevin Bilbee -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Darin CoxSent: Tuesday, February 14, 2006 6:31 AMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 8:51 AM Subject: [Declude.JunkMail] large mail to large number op recips Hi, We are a school and: - sometimes someone needs to send a large e-mail (20-30 MB) to one of the staf or students. - several times a day we send e-mails to large groups of students so the BCC field might contain up to 1500 addresses. Both items are no problem until they are combined like some tried today. :-( Suddenly I lost around 15GB of diskspace on my mailserver. At least that is what IMail tried because I only had about 10GB left on my mailbox drive. Guess what happened? Is there a way using Declude Junkmail to flag this situation and stopping the e-mail while still allowing the two items above? I'm currently using Declude 2.16, Junkmail Std and AV Pro. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl
[Declude.JunkMail] OT: POP Account
I am looking for a single POP account on a highly reliable server with a long standing reputable company. I have found Lycose, NetZero, FuseMail. any suggestion/comments Kevin Bilbee Network Administrator Standard Abrasives, Inc. [EMAIL PROTECTED] (805) 520-5800 x7332 Changing the way industry works. --- [This E-mail was scanned for viruses by Declude EVA www.declude.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.
Re: [Declude.JunkMail] large mail to large number op recips
Did you check the logging of your external tests to make sure? I generally find no log lines in the JunkMail logs for tests that failed, or maybe just something like the LEGITCONTENT test, but the external tests' logs show that they were in fact run for everything besides WHITELIST AUTH. Matt Scott Fisher wrote: In 3.x WHITELIST IP does skip the tests. I have very rare occurances (10 this month) where some WHITELIST AUTH do have tests run but the weight is set to 0. (3.0.5.23) - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 12:07 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips PREWHITELIST ON isn't working completely anyway, at least in 2.x. I would like to have it fixed though. Here's an example: WHITELIST AUTH still skips tests with PREWHITELIST ON, but using actions in your global.cfg like WHITELIST IP or WHITELIST SUBJECT will result in tests being run. This used to not be the case. It will whitelist the message though, it just won't skip running the tests. Maybe it was fixed in a 3.x release, but I haven't seen any mentions of it being addressed. Matt Scott Fisher wrote: E... that'll popup the CPU time. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:29 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips I just want to help prevent confusion here, and I'm thinking that you might not be all the way up the thread yet. You are of course correct on how to do this with Declude Pro 2.0.6.16 so long as the users aren't whitelisted. I suspect that they are however since they are internal and that is generally considered to be a best practice, and if they are, they either need to turn off whitelisting (which might not be preferable), or use another method such as have the script modify the E-mail's D* file while setting PREWHITELIST OFF in order to ensure that such scripts are run. Matt Scott Fisher wrote: If they were BCCs... You could set a BCC threshold using the internal Declude bcc test BCC-50 bcc 10 x 10 0 also run a size test: SIZE-GT-1MB external 18 "D:\vb\Size.exe PATH=d:\vb\ LOGLEVEL=ERRORSONLY SZ=5,1000,5000,1,10,20,50,100" 0 0 Then have a combo filter TESTSFAILED END NOTCONTAINS BCC-50 TESTSFAILED 0 CONTAINS SIZE-GT-1MB so every email with 50 bcc's and >1 MB would trigger the filter. If they aren't bcc's, then you are into vba land. a link to Matt's vbs is here. I compiled it into a exe. that link is there too. http://it.farmprogress.com/declude\declude.htm - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 10:29 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips See Matt's reply. IIRC, both he and Scott Fisher had variants on the size test, one was _vbscript_ and the other was an EXE. You might check's Scott's website as he had compiled a list of tools and scripts he uses. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:18 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Indeed that is what I want, to catch the exceptions. So WHO has the tool Darin is talking about? Anyone? How can I determine whether recipients * mailsize > treshold I could indeed simply create a test for it and have those mails put aside. Met vriendelijke groet, Bonno Bloksma hoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhoven t 040 296 28 28 / f 040 237 35 20 [EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 4:07 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips
Re: [Declude.JunkMail] large mail to large number op recips
In 3.x WHITELIST IP does skip the tests. I have very rare occurances (10 this month) where some WHITELIST AUTH do have tests run but the weight is set to 0. (3.0.5.23) - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 12:07 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips PREWHITELIST ON isn't working completely anyway, at least in 2.x. I would like to have it fixed though. Here's an example:WHITELIST AUTH still skips tests with PREWHITELIST ON, but using actions in your global.cfg like WHITELIST IP or WHITELIST SUBJECT will result in tests being run. This used to not be the case. It will whitelist the message though, it just won't skip running the tests. Maybe it was fixed in a 3.x release, but I haven't seen any mentions of it being addressed.MattScott Fisher wrote: E... that'll popup the CPU time. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:29 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips I just want to help prevent confusion here, and I'm thinking that you might not be all the way up the thread yet. You are of course correct on how to do this with Declude Pro 2.0.6.16 so long as the users aren't whitelisted. I suspect that they are however since they are internal and that is generally considered to be a best practice, and if they are, they either need to turn off whitelisting (which might not be preferable), or use another method such as have the script modify the E-mail's D* file while setting PREWHITELIST OFF in order to ensure that such scripts are run.MattScott Fisher wrote: If they were BCCs... You could set a BCC threshold using the internal Declude bcc test BCC-50 bcc 10 x 10 0 also run a size test: SIZE-GT-1MB external 18 "D:\vb\Size.exe PATH=d:\vb\ LOGLEVEL=ERRORSONLY SZ=5,1000,5000,1,10,20,50,100" 0 0 Then have a combo filter TESTSFAILED END NOTCONTAINS BCC-50 TESTSFAILED 0 CONTAINS SIZE-GT-1MB so every email with 50 bcc's and >1 MB would trigger the filter. If they aren't bcc's, then you are into vba land. a link to Matt's vbs is here. I compiled it into a exe. that link is there too. http://it.farmprogress.com/declude\declude.htm - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 10:29 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips See Matt's reply. IIRC, both he and Scott Fisher had variants on the size test, one was _vbscript_ and the other was an EXE. You might check's Scott's website as he had compiled a list of tools and scripts he uses. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:18 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Indeed that is what I want, to catch the exceptions. So WHO has the tool Darin is talking about? Anyone? How can I determine whether recipients * mailsize > treshold I could indeed simply create a test for it and have those mails put aside. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 4:07 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the
Re: [Declude.JunkMail] large mail to large number op recips
Hi Kevin, I think the point Bonno was making was that it was the combination of file size AND number of recipients that was the problem. He probably has a file size limit in place, but when a 10MB attachment goes to 100 people, you're suddenly at 1.2-1.4 GB of disk space used. Yes, he could limit number of recipients as well, but that would unnecessarily limit other broadcast messages on his network. I think we all understand the education issue, but also know we have to take steps to protect ourselves against users who forget, don't realize, or just plain ignore the policies we put in place. Darin. - Original Message - From: Kevin Bilbee To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 1:06 PM Subject: RE: [Declude.JunkMail] large mail to large number op recips I realize this was an accident mailing but you should have in place attachment size limits to avoid sucking the disk space of the mail server and to avoit filling up mailboxes to unrealistic sizes. On average an attachment will become 20% larger once encoded in an email. Users should know a 10mb file attachment will take up about 12mb of mailbox space and will be viewed as a 12mb attachement. I would limit the size of attachments to no more that 10mb in the mail server to start. Then I would setup an upload/download for files larger than 10mb. Educate your users on how sending large files can cause all kinds of problems. Like send/receive timing out and resetting, resulting in dulpicate mssages being downloaded. I get calls all the time to delete large messages from mail boxes on domains that pay to not have a file size attachemnt limit. Kevin Bilbee -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Darin CoxSent: Tuesday, February 14, 2006 6:31 AMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 8:51 AM Subject: [Declude.JunkMail] large mail to large number op recips Hi, We are a school and: - sometimes someone needs to send a large e-mail (20-30 MB) to one of the staf or students. - several times a day we send e-mails to large groups of students so the BCC field might contain up to 1500 addresses. Both items are no problem until they are combined like some tried today. :-( Suddenly I lost around 15GB of diskspace on my mailserver. At least that is what IMail tried because I only had about 10GB left on my mailbox drive. Guess what happened? Is there a way using Declude Junkmail to flag this situation and stopping the e-mail while still allowing the two items above? I'm currently using Declude 2.16, Junkmail Std and AV Pro. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl
RE: [Declude.JunkMail] large mail to large number op recips
I realize this was an accident mailing but you should have in place attachment size limits to avoid sucking the disk space of the mail server and to avoit filling up mailboxes to unrealistic sizes. On average an attachment will become 20% larger once encoded in an email. Users should know a 10mb file attachment will take up about 12mb of mailbox space and will be viewed as a 12mb attachement. I would limit the size of attachments to no more that 10mb in the mail server to start. Then I would setup an upload/download for files larger than 10mb. Educate your users on how sending large files can cause all kinds of problems. Like send/receive timing out and resetting, resulting in dulpicate mssages being downloaded. I get calls all the time to delete large messages from mail boxes on domains that pay to not have a file size attachemnt limit. Kevin Bilbee -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Darin CoxSent: Tuesday, February 14, 2006 6:31 AMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 8:51 AM Subject: [Declude.JunkMail] large mail to large number op recips Hi, We are a school and: - sometimes someone needs to send a large e-mail (20-30 MB) to one of the staf or students. - several times a day we send e-mails to large groups of students so the BCC field might contain up to 1500 addresses. Both items are no problem until they are combined like some tried today. :-( Suddenly I lost around 15GB of diskspace on my mailserver. At least that is what IMail tried because I only had about 10GB left on my mailbox drive. Guess what happened? Is there a way using Declude Junkmail to flag this situation and stopping the e-mail while still allowing the two items above? I'm currently using Declude 2.16, Junkmail Std and AV Pro. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl
Re: [Declude.JunkMail] large mail to large number op recips
PREWHITELIST ON isn't working completely anyway, at least in 2.x. I would like to have it fixed though. Here's an example: WHITELIST AUTH still skips tests with PREWHITELIST ON, but using actions in your global.cfg like WHITELIST IP or WHITELIST SUBJECT will result in tests being run. This used to not be the case. It will whitelist the message though, it just won't skip running the tests. Maybe it was fixed in a 3.x release, but I haven't seen any mentions of it being addressed. Matt Scott Fisher wrote: E... that'll popup the CPU time. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:29 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips I just want to help prevent confusion here, and I'm thinking that you might not be all the way up the thread yet. You are of course correct on how to do this with Declude Pro 2.0.6.16 so long as the users aren't whitelisted. I suspect that they are however since they are internal and that is generally considered to be a best practice, and if they are, they either need to turn off whitelisting (which might not be preferable), or use another method such as have the script modify the E-mail's D* file while setting PREWHITELIST OFF in order to ensure that such scripts are run. Matt Scott Fisher wrote: If they were BCCs... You could set a BCC threshold using the internal Declude bcc test BCC-50 bcc 10 x 10 0 also run a size test: SIZE-GT-1MB external 18 "D:\vb\Size.exe PATH=d:\vb\ LOGLEVEL=ERRORSONLY SZ=5,1000,5000,1,10,20,50,100" 0 0 Then have a combo filter TESTSFAILED END NOTCONTAINS BCC-50 TESTSFAILED 0 CONTAINS SIZE-GT-1MB so every email with 50 bcc's and >1 MB would trigger the filter. If they aren't bcc's, then you are into vba land. a link to Matt's vbs is here. I compiled it into a exe. that link is there too. http://it.farmprogress.com/declude\declude.htm - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 10:29 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips See Matt's reply. IIRC, both he and Scott Fisher had variants on the size test, one was _vbscript_ and the other was an EXE. You might check's Scott's website as he had compiled a list of tools and scripts he uses. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:18 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Indeed that is what I want, to catch the exceptions. So WHO has the tool Darin is talking about? Anyone? How can I determine whether recipients * mailsize > treshold I could indeed simply create a test for it and have those mails put aside. Met vriendelijke groet, Bonno Bloksma hoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhoven t 040 296 28 28 / f 040 237 35 20 [EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 4:07 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the number of recipients in combination with this to perform a custom action like routing or deleting... or route it to a program alias that sends you an alert notification. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 9:46 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Nope, we don't want to go that way for ALL mail. We''ve got several options to upload files for several purpouses within our school. Our website has lot's of option for that but.. sometimes we want to send something as an attachment. In this case it was a newsletter for our staf which was supposed to be about 200-300 KB, we want those
[Declude.JunkMail] Win a FREE Copy of ?
Okay, it's time for all of us at Declude to face the facts: naming products is not our strength and naming our latest release Version 4 showed both a lack of imagination and an ability to cause confusion. After all, we wouldn't name our latest child Version 2! At least most of us wouldn't Realizing that we are pretty good at designing software and pretty bad at naming it, we thought we would let you have a go at naming this latest release. Please, nothing provocative or off-color, unless it's particularly good. In any case, don't be afraid to let imagination run rampant. We need your suggestions no later than 5pm Eastern Time on Wednesday, February 15th. At that point we will have a run off vote that will end this Friday, February 17th. The winning name will receive a free copy of ? (Currently known as Version 4) and a free one year service agreement on your current software. All names should be submitted by email to [EMAIL PROTECTED] The back of napkins, prescription pads, Dunkin' Donuts cups, bar coasters and Subway sandwich wraps will not be accepted as valid entries. All employees of Declude and their families are ineligible. Good luck! --- [This E-mail was scanned for viruses by Declude EVA www.declude.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.
Re: [Declude.JunkMail] large mail to large number op recips
That was fixed in the version that Bonno is running (2.0.6.16). I have also tested things and found that it will accept pretty much unlimited characters in a command line argument, so there is no danger in passing in %RECIPIENTS% to the script through Declude. Matt Scott Fisher wrote: One other possible issue: I've seen problems with external tests and very long command lines. A long (>256) command line could return odd results. I don't know if that was every fixed. It is definitely safe to use the bitmask test. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 10:57 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Bonno, There are two _vbscript_ examples on my site: http://www.mailpure.com/software/decludefilters/beta/ "Size" would be a good place to start, but you can also get hints at how to do some other things with the "BlankSubject" script. Those are the only two in _vbscript_. You would configure the script in your Global.cfg like so: BIGBCC external 10 "CScript C:\IMail\Declude\Filters\BigBCC.vbs //B //NoLogo //T:30 RE=%RECIPIENTS%" 0 0 That will pass in all the recipients as an argument to the script, and you can then parse them out fairly easily. Declude automatically inserts the D* file location as the last argument. It will also pass in the message size, but that is easy to find and some code for that is in the "Size" script. I would imagine that you would want to prevent anything over a certain size from being sent to more than a certain number of recipients. Pay careful attention to the caveats. You likely have your own users whitelisted in Declude using WHITELIST AUTH. This will cause actions on this test to not be applied, and you also don't want to remove it. The best way to handle these circumstances is to delete or move the D* file when the script finds an issue, and let Declude just error, or maybe trim the D* message size to just 32 KB or something like that. You also should make sure that PREWHITELIST OFF is set in your config. While this will presently work with PREWHITELIST ON, if they fix that, it will suddenly stop working since that is a bug. Since you aren't using Declude for scoring the message or any message actions, you would want to make sure to exit the script with WScript.Quit(0). You might have your programmer join the list and ask for pointers when they need some direction. There are a few of us around here that have done _vbscript_ plug-ins for Declude, and it can be confusing if you don't fully understand what is going on, yet very powerful if you can figure it out. Matt Bonno Bloksma wrote: Hi, I can not do it, I'm not that good with _vbscript_ but we have people who can do it. How would I attach this script to the mail IMail/Declude chain. Use the undocumented DAISYCHAIN option in Declude? If so, what is the correct keyword ans in which file do I put it? Met vriendelijke groet, Bonno Bloksma hoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhoven t 040 296 28 28 / f 040 237 35 20 [EMAIL PROTECTED] / www.tio.nl - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 4:51 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips You can write it in _vbscript_ and pass the recipients into the script with the argument %RECIPIENTS% Once you have the number of recipients (found by counting the @ symbols in that argument), you can then get the message size and do some multiplication. Here's one big issue though. If you whitelist your own users, as most of us do, this filter won't work, or at least it shouldn't work. There is a bug though introduced in 2.x that causes all tests to run despite the sender being whitelisted, but it will cause messages to still score 0 (just wastes resources). Therefore you might try just deleting or moving the message file with the script instead of filtering it with Declude. Matt Darin Cox wrote: Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the number of recipients in combination with this to perform a custom action like routing or deleting... or route it to a program alias that sends you an alert notification. Darin. - Original Message - From: Bonno Bloks
Re: [Declude.JunkMail] large mail to large number op recips
E... that'll popup the CPU time. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:29 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips I just want to help prevent confusion here, and I'm thinking that you might not be all the way up the thread yet. You are of course correct on how to do this with Declude Pro 2.0.6.16 so long as the users aren't whitelisted. I suspect that they are however since they are internal and that is generally considered to be a best practice, and if they are, they either need to turn off whitelisting (which might not be preferable), or use another method such as have the script modify the E-mail's D* file while setting PREWHITELIST OFF in order to ensure that such scripts are run.MattScott Fisher wrote: If they were BCCs... You could set a BCC threshold using the internal Declude bcc test BCC-50 bcc 10 x 10 0 also run a size test: SIZE-GT-1MB external 18 "D:\vb\Size.exe PATH=d:\vb\ LOGLEVEL=ERRORSONLY SZ=5,1000,5000,1,10,20,50,100" 0 0 Then have a combo filter TESTSFAILED END NOTCONTAINS BCC-50 TESTSFAILED 0 CONTAINS SIZE-GT-1MB so every email with 50 bcc's and >1 MB would trigger the filter. If they aren't bcc's, then you are into vba land. a link to Matt's vbs is here. I compiled it into a exe. that link is there too. http://it.farmprogress.com/declude\declude.htm - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 10:29 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips See Matt's reply. IIRC, both he and Scott Fisher had variants on the size test, one was _vbscript_ and the other was an EXE. You might check's Scott's website as he had compiled a list of tools and scripts he uses. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:18 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Indeed that is what I want, to catch the exceptions. So WHO has the tool Darin is talking about? Anyone? How can I determine whether recipients * mailsize > treshold I could indeed simply create a test for it and have those mails put aside. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 4:07 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the number of recipients in combination with this to perform a custom action like routing or deleting... or route it to a program alias that sends you an alert notification. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 9:46 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Nope, we don't want to go that way for ALL mail. We''ve got several options to upload files for several purpouses within our school. Our website has lot's of option for that but.. sometimes we want to send something as an attachment. In this case it was a newsletter for our staf which was supposed to be about 200-300 KB, we want those newsletters sent as attachment, not as a link. For some reason the newsletter ended up to be a Word document 5MB large and was sent without realising it. After that it was sent once more. This time as a PDF file... which happened to be 33MB large and was created using the Word document as a base. :-( Both mails went to 250+ recipients. The first mail did not kill the mailserver, the second did. :-( For exceptions like
Re: [Declude.JunkMail] How would I catch email like this?
Implement a URI filtering type application like our invURIBL. The domain in the email is listed in both SURBL and URIBL and would have been caught. Non-authoritative answer: Name:benawarde.com.multi.surbl.org Address: 127.0.0.102 Non-authoritative answer: Name:benawarde.com.multi.uribl.com Address: 127.0.0.2 Darrell --- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. mail-lists writes: Never seen an e-mail like this.. Obviously didn't hit my bodyfilter for VIAGRA or VALIUM. Not quite sure how to scan for something like this. Or even give a better description of what it is.. When viewing it in html if I go to highlight the readable text, it also highlights the garbled text on the right side of the page. Thanks! Here is the body in plain text. Hello VyI w AvGiRbAs j $r3j,s7c5 y VvAaL r l p U n Mu b$k1u,k2 p 1dCqIvA o LpImS n w $ r 3s,h3 m 3k and many other http://www.benawarde.com Here is the HTML.. Hello VyI w AvGiRbAs j $r3j,s7c5 y VvAaL r l p U n Mu b$k1u,k2 p 1d CqIvA o LpImS n w $ r 3s,h3 m 3k and many other http://www.benawarde.com";>size=2>http://www.benawarde.com Confidentiality Notice: The information contained in this transmission is intended only for the personal and confidential use of the designated recipient named above. If the receiver of this transmission is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error, and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you are not the intended recipient, please immediately notify the sender and delete this e-mail message from your system. --- [This E-mail was scanned for viruses by Declude EVA www.declude.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 was scanned for viruses by Declude EVA www.declude.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.
Re: [Declude.JunkMail] large mail to large number op recips
I just want to help prevent confusion here, and I'm thinking that you might not be all the way up the thread yet. You are of course correct on how to do this with Declude Pro 2.0.6.16 so long as the users aren't whitelisted. I suspect that they are however since they are internal and that is generally considered to be a best practice, and if they are, they either need to turn off whitelisting (which might not be preferable), or use another method such as have the script modify the E-mail's D* file while setting PREWHITELIST OFF in order to ensure that such scripts are run. Matt Scott Fisher wrote: If they were BCCs... You could set a BCC threshold using the internal Declude bcc test BCC-50 bcc 10 x 10 0 also run a size test: SIZE-GT-1MB external 18 "D:\vb\Size.exe PATH=d:\vb\ LOGLEVEL=ERRORSONLY SZ=5,1000,5000,1,10,20,50,100" 0 0 Then have a combo filter TESTSFAILED END NOTCONTAINS BCC-50 TESTSFAILED 0 CONTAINS SIZE-GT-1MB so every email with 50 bcc's and >1 MB would trigger the filter. If they aren't bcc's, then you are into vba land. a link to Matt's vbs is here. I compiled it into a exe. that link is there too. http://it.farmprogress.com/declude\declude.htm - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 10:29 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips See Matt's reply. IIRC, both he and Scott Fisher had variants on the size test, one was _vbscript_ and the other was an EXE. You might check's Scott's website as he had compiled a list of tools and scripts he uses. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:18 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Indeed that is what I want, to catch the exceptions. So WHO has the tool Darin is talking about? Anyone? How can I determine whether recipients * mailsize > treshold I could indeed simply create a test for it and have those mails put aside. Met vriendelijke groet, Bonno Bloksma hoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhoven t 040 296 28 28 / f 040 237 35 20 [EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 4:07 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the number of recipients in combination with this to perform a custom action like routing or deleting... or route it to a program alias that sends you an alert notification. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 9:46 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Nope, we don't want to go that way for ALL mail. We''ve got several options to upload files for several purpouses within our school. Our website has lot's of option for that but.. sometimes we want to send something as an attachment. In this case it was a newsletter for our staf which was supposed to be about 200-300 KB, we want those newsletters sent as attachment, not as a link. For some reason the newsletter ended up to be a Word document 5MB large and was sent without realising it. After that it was sent once more. This time as a PDF file... which happened to be 33MB large and was created using the Word document as a base. :-( Both mails went to 250+ recipients. The first mail did not kill the mailserver, the second did. :-( For exceptions like these I want to have a tool to catch them before it fills up the server. Met vriendelijke groet, Bonno Bloksma hoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhoven t 040 296 28 28 / f 040 237 35 20 [EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 3:31 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this
Re: [Declude.JunkMail] large mail to large number op recips
One other possible issue: I've seen problems with external tests and very long command lines. A long (>256) command line could return odd results. I don't know if that was every fixed. It is definitely safe to use the bitmask test. - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 10:57 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Bonno,There are two _vbscript_ examples on my site: http://www.mailpure.com/software/decludefilters/beta/"Size" would be a good place to start, but you can also get hints at how to do some other things with the "BlankSubject" script. Those are the only two in _vbscript_.You would configure the script in your Global.cfg like so:BIGBCC external 10 "CScript C:\IMail\Declude\Filters\BigBCC.vbs //B //NoLogo //T:30 RE=%RECIPIENTS%" 0 0That will pass in all the recipients as an argument to the script, and you can then parse them out fairly easily. Declude automatically inserts the D* file location as the last argument. It will also pass in the message size, but that is easy to find and some code for that is in the "Size" script. I would imagine that you would want to prevent anything over a certain size from being sent to more than a certain number of recipients.Pay careful attention to the caveats. You likely have your own users whitelisted in Declude using WHITELIST AUTH. This will cause actions on this test to not be applied, and you also don't want to remove it. The best way to handle these circumstances is to delete or move the D* file when the script finds an issue, and let Declude just error, or maybe trim the D* message size to just 32 KB or something like that. You also should make sure that PREWHITELIST OFF is set in your config. While this will presently work with PREWHITELIST ON, if they fix that, it will suddenly stop working since that is a bug. Since you aren't using Declude for scoring the message or any message actions, you would want to make sure to exit the script with WScript.Quit(0).You might have your programmer join the list and ask for pointers when they need some direction. There are a few of us around here that have done _vbscript_ plug-ins for Declude, and it can be confusing if you don't fully understand what is going on, yet very powerful if you can figure it out.MattBonno Bloksma wrote: Hi, I can not do it, I'm not that good with _vbscript_ but we have people who can do it. How would I attach this script to the mail IMail/Declude chain. Use the undocumented DAISYCHAIN option in Declude? If so, what is the correct keyword ans in which file do I put it? Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 4:51 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips You can write it in _vbscript_ and pass the recipients into the script with the argument %RECIPIENTS%Once you have the number of recipients (found by counting the @ symbols in that argument), you can then get the message size and do some multiplication.Here's one big issue though. If you whitelist your own users, as most of us do, this filter won't work, or at least it shouldn't work. There is a bug though introduced in 2.x that causes all tests to run despite the sender being whitelisted, but it will cause messages to still score 0 (just wastes resources). Therefore you might try just deleting or moving the message file with the script instead of filtering it with Declude.MattDarin Cox wrote: Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the number of recipients in combination with this to perform a custom action like routing or deleting... or route it to a program alias that sends you an alert notification. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 9:46 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Nope, we don't want to go that way for ALL
Re: [Declude.JunkMail] large mail to large number op recips
If they were BCCs... You could set a BCC threshold using the internal Declude bcc test BCC-50 bcc 10 x 10 0 also run a size test: SIZE-GT-1MB external 18 "D:\vb\Size.exe PATH=d:\vb\ LOGLEVEL=ERRORSONLY SZ=5,1000,5000,1,10,20,50,100" 0 0 Then have a combo filter TESTSFAILED END NOTCONTAINS BCC-50 TESTSFAILED 0 CONTAINS SIZE-GT-1MB so every email with 50 bcc's and >1 MB would trigger the filter. If they aren't bcc's, then you are into vba land. a link to Matt's vbs is here. I compiled it into a exe. that link is there too. http://it.farmprogress.com/declude\declude.htm - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 10:29 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips See Matt's reply. IIRC, both he and Scott Fisher had variants on the size test, one was _vbscript_ and the other was an EXE. You might check's Scott's website as he had compiled a list of tools and scripts he uses. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:18 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Indeed that is what I want, to catch the exceptions. So WHO has the tool Darin is talking about? Anyone? How can I determine whether recipients * mailsize > treshold I could indeed simply create a test for it and have those mails put aside. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 4:07 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the number of recipients in combination with this to perform a custom action like routing or deleting... or route it to a program alias that sends you an alert notification. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 9:46 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Nope, we don't want to go that way for ALL mail. We''ve got several options to upload files for several purpouses within our school. Our website has lot's of option for that but.. sometimes we want to send something as an attachment. In this case it was a newsletter for our staf which was supposed to be about 200-300 KB, we want those newsletters sent as attachment, not as a link. For some reason the newsletter ended up to be a Word document 5MB large and was sent without realising it. After that it was sent once more. This time as a PDF file... which happened to be 33MB large and was created using the Word document as a base. :-( Both mails went to 250+ recipients. The first mail did not kill the mailserver, the second did. :-( For exceptions like these I want to have a tool to catch them before it fills up the server. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 3:31 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 8:51
Re: [Declude.JunkMail] large mail to large number op recips
Bonno, There are two _vbscript_ examples on my site: http://www.mailpure.com/software/decludefilters/beta/ "Size" would be a good place to start, but you can also get hints at how to do some other things with the "BlankSubject" script. Those are the only two in _vbscript_. You would configure the script in your Global.cfg like so: BIGBCC external 10 "CScript C:\IMail\Declude\Filters\BigBCC.vbs //B //NoLogo //T:30 RE=%RECIPIENTS%" 0 0 That will pass in all the recipients as an argument to the script, and you can then parse them out fairly easily. Declude automatically inserts the D* file location as the last argument. It will also pass in the message size, but that is easy to find and some code for that is in the "Size" script. I would imagine that you would want to prevent anything over a certain size from being sent to more than a certain number of recipients. Pay careful attention to the caveats. You likely have your own users whitelisted in Declude using WHITELIST AUTH. This will cause actions on this test to not be applied, and you also don't want to remove it. The best way to handle these circumstances is to delete or move the D* file when the script finds an issue, and let Declude just error, or maybe trim the D* message size to just 32 KB or something like that. You also should make sure that PREWHITELIST OFF is set in your config. While this will presently work with PREWHITELIST ON, if they fix that, it will suddenly stop working since that is a bug. Since you aren't using Declude for scoring the message or any message actions, you would want to make sure to exit the script with WScript.Quit(0). You might have your programmer join the list and ask for pointers when they need some direction. There are a few of us around here that have done _vbscript_ plug-ins for Declude, and it can be confusing if you don't fully understand what is going on, yet very powerful if you can figure it out. Matt Bonno Bloksma wrote: Hi, I can not do it, I'm not that good with _vbscript_ but we have people who can do it. How would I attach this script to the mail IMail/Declude chain. Use the undocumented DAISYCHAIN option in Declude? If so, what is the correct keyword ans in which file do I put it? Met vriendelijke groet, Bonno Bloksma hoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhoven t 040 296 28 28 / f 040 237 35 20 [EMAIL PROTECTED] / www.tio.nl - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 4:51 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips You can write it in _vbscript_ and pass the recipients into the script with the argument %RECIPIENTS% Once you have the number of recipients (found by counting the @ symbols in that argument), you can then get the message size and do some multiplication. Here's one big issue though. If you whitelist your own users, as most of us do, this filter won't work, or at least it shouldn't work. There is a bug though introduced in 2.x that causes all tests to run despite the sender being whitelisted, but it will cause messages to still score 0 (just wastes resources). Therefore you might try just deleting or moving the message file with the script instead of filtering it with Declude. Matt Darin Cox wrote: Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the number of recipients in combination with this to perform a custom action like routing or deleting... or route it to a program alias that sends you an alert notification. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 9:46 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Nope, we don't want to go that way for ALL mail. We''ve got several options to upload files for several purpouses within our school. Our website has lot's of option for that but.. sometimes we want to send something as an attachment. In this case it was a newsletter for our staf which was supposed to be about 200-300 KB, we want those newsletters sent as attachment, not as a link. For some reason the newsletter ended up to be a Word document 5MB large and was sent without realising it. After that it was sent once more. This time as a PDF file... which happened to be 33MB large and was created using the Word document as a base. :-( Both mails went to 250+ recipients. The first mail did not kill the mailserver, the second did. :-( For excep
Re: [Declude.JunkMail] large mail to large number op recips
Darin, Since this is for internal users, I'm guessing that they are whitelisted and therefore any Declude actions wouldn't work, and they probably wouldn't want to turn the whitelisting off. Matt Darin Cox wrote: Nope. Implement as an external test, then make a combo filter to check the separate size and recipients tests and perform the desired action. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:22 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, I can not do it, I'm not that good with _vbscript_ but we have people who can do it. How would I attach this script to the mail IMail/Declude chain. Use the undocumented DAISYCHAIN option in Declude? If so, what is the correct keyword ans in which file do I put it? Met vriendelijke groet, Bonno Bloksma hoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhoven t 040 296 28 28 / f 040 237 35 20 [EMAIL PROTECTED] / www.tio.nl - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 4:51 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips You can write it in _vbscript_ and pass the recipients into the script with the argument %RECIPIENTS% Once you have the number of recipients (found by counting the @ symbols in that argument), you can then get the message size and do some multiplication. Here's one big issue though. If you whitelist your own users, as most of us do, this filter won't work, or at least it shouldn't work. There is a bug though introduced in 2.x that causes all tests to run despite the sender being whitelisted, but it will cause messages to still score 0 (just wastes resources). Therefore you might try just deleting or moving the message file with the script instead of filtering it with Declude. Matt Darin Cox wrote: Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the number of recipients in combination with this to perform a custom action like routing or deleting... or route it to a program alias that sends you an alert notification. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 9:46 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Nope, we don't want to go that way for ALL mail. We''ve got several options to upload files for several purpouses within our school. Our website has lot's of option for that but.. sometimes we want to send something as an attachment. In this case it was a newsletter for our staf which was supposed to be about 200-300 KB, we want those newsletters sent as attachment, not as a link. For some reason the newsletter ended up to be a Word document 5MB large and was sent without realising it. After that it was sent once more. This time as a PDF file... which happened to be 33MB large and was created using the Word document as a base. :-( Both mails went to 250+ recipients. The first mail did not kill the mailserver, the second did. :-( For exceptions like these I want to have a tool to catch them before it fills up the server. Met vriendelijke groet, Bonno Bloksma hoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhoven t 040 296 28 28 / f 040 237 35 20 [EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 3:31 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declu
Re: [Declude.JunkMail] large mail to large number op recips
Nope. Implement as an external test, then make a combo filter to check the separate size and recipients tests and perform the desired action. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:22 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, I can not do it, I'm not that good with _vbscript_ but we have people who can do it. How would I attach this script to the mail IMail/Declude chain. Use the undocumented DAISYCHAIN option in Declude? If so, what is the correct keyword ans in which file do I put it? Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 4:51 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips You can write it in _vbscript_ and pass the recipients into the script with the argument %RECIPIENTS%Once you have the number of recipients (found by counting the @ symbols in that argument), you can then get the message size and do some multiplication.Here's one big issue though. If you whitelist your own users, as most of us do, this filter won't work, or at least it shouldn't work. There is a bug though introduced in 2.x that causes all tests to run despite the sender being whitelisted, but it will cause messages to still score 0 (just wastes resources). Therefore you might try just deleting or moving the message file with the script instead of filtering it with Declude.MattDarin Cox wrote: Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the number of recipients in combination with this to perform a custom action like routing or deleting... or route it to a program alias that sends you an alert notification. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 9:46 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Nope, we don't want to go that way for ALL mail. We''ve got several options to upload files for several purpouses within our school. Our website has lot's of option for that but.. sometimes we want to send something as an attachment. In this case it was a newsletter for our staf which was supposed to be about 200-300 KB, we want those newsletters sent as attachment, not as a link. For some reason the newsletter ended up to be a Word document 5MB large and was sent without realising it. After that it was sent once more. This time as a PDF file... which happened to be 33MB large and was created using the Word document as a base. :-( Both mails went to 250+ recipients. The first mail did not kill the mailserver, the second did. :-( For exceptions like these I want to have a tool to catch them before it fills up the server. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 3:31 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 8:51 AM Subject: [Declude.JunkMail] large mail to large number op recips Hi, We are a school and: - sometimes someone needs to send a
Re: [Declude.JunkMail] large mail to large number op recips
See Matt's reply. IIRC, both he and Scott Fisher had variants on the size test, one was _vbscript_ and the other was an EXE. You might check's Scott's website as he had compiled a list of tools and scripts he uses. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 11:18 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Indeed that is what I want, to catch the exceptions. So WHO has the tool Darin is talking about? Anyone? How can I determine whether recipients * mailsize > treshold I could indeed simply create a test for it and have those mails put aside. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 4:07 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the number of recipients in combination with this to perform a custom action like routing or deleting... or route it to a program alias that sends you an alert notification. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 9:46 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Nope, we don't want to go that way for ALL mail. We''ve got several options to upload files for several purpouses within our school. Our website has lot's of option for that but.. sometimes we want to send something as an attachment. In this case it was a newsletter for our staf which was supposed to be about 200-300 KB, we want those newsletters sent as attachment, not as a link. For some reason the newsletter ended up to be a Word document 5MB large and was sent without realising it. After that it was sent once more. This time as a PDF file... which happened to be 33MB large and was created using the Word document as a base. :-( Both mails went to 250+ recipients. The first mail did not kill the mailserver, the second did. :-( For exceptions like these I want to have a tool to catch them before it fills up the server. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 3:31 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 8:51 AM Subject: [Declude.JunkMail] large mail to large number op recips Hi, We are a school and: - sometimes someone needs to send a large e-mail (20-30 MB) to one of the staf or students. - several times a day we send e-mails to large groups of students so the BCC field might contain up to 1500 addresses. Both items are no problem until they are combined like some tried today. :-( Suddenly I lost around 15GB of diskspace on my mailserver. At least that is what IMail tried because I only had about 10GB left on my mailbox drive. Guess what happened? Is there a way using Declude Junkmail to flag this situation and stopping the e-mail while still allowing the two items above? I'm currently using Declude 2.16, Junkmail Std and AV Pro. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl
Re: [Declude.JunkMail] large mail to large number op recips
Hi, Indeed that is what I want, to catch the exceptions. So WHO has the tool Darin is talking about? Anyone? How can I determine whether recipients * mailsize > treshold I could indeed simply create a test for it and have those mails put aside. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 4:07 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the number of recipients in combination with this to perform a custom action like routing or deleting... or route it to a program alias that sends you an alert notification. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 9:46 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Nope, we don't want to go that way for ALL mail. We''ve got several options to upload files for several purpouses within our school. Our website has lot's of option for that but.. sometimes we want to send something as an attachment. In this case it was a newsletter for our staf which was supposed to be about 200-300 KB, we want those newsletters sent as attachment, not as a link. For some reason the newsletter ended up to be a Word document 5MB large and was sent without realising it. After that it was sent once more. This time as a PDF file... which happened to be 33MB large and was created using the Word document as a base. :-( Both mails went to 250+ recipients. The first mail did not kill the mailserver, the second did. :-( For exceptions like these I want to have a tool to catch them before it fills up the server. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 3:31 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 8:51 AM Subject: [Declude.JunkMail] large mail to large number op recips Hi, We are a school and: - sometimes someone needs to send a large e-mail (20-30 MB) to one of the staf or students. - several times a day we send e-mails to large groups of students so the BCC field might contain up to 1500 addresses. Both items are no problem until they are combined like some tried today. :-( Suddenly I lost around 15GB of diskspace on my mailserver. At least that is what IMail tried because I only had about 10GB left on my mailbox drive. Guess what happened? Is there a way using Declude Junkmail to flag this situation and stopping the e-mail while still allowing the two items above? I'm currently using Declude 2.16, Junkmail Std and AV Pro. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl
Re: [Declude.JunkMail] large mail to large number op recips
Hi, I can not do it, I'm not that good with _vbscript_ but we have people who can do it. How would I attach this script to the mail IMail/Declude chain. Use the undocumented DAISYCHAIN option in Declude? If so, what is the correct keyword ans in which file do I put it? Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 4:51 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips You can write it in _vbscript_ and pass the recipients into the script with the argument %RECIPIENTS%Once you have the number of recipients (found by counting the @ symbols in that argument), you can then get the message size and do some multiplication.Here's one big issue though. If you whitelist your own users, as most of us do, this filter won't work, or at least it shouldn't work. There is a bug though introduced in 2.x that causes all tests to run despite the sender being whitelisted, but it will cause messages to still score 0 (just wastes resources). Therefore you might try just deleting or moving the message file with the script instead of filtering it with Declude.MattDarin Cox wrote: Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the number of recipients in combination with this to perform a custom action like routing or deleting... or route it to a program alias that sends you an alert notification. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 9:46 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Nope, we don't want to go that way for ALL mail. We''ve got several options to upload files for several purpouses within our school. Our website has lot's of option for that but.. sometimes we want to send something as an attachment. In this case it was a newsletter for our staf which was supposed to be about 200-300 KB, we want those newsletters sent as attachment, not as a link. For some reason the newsletter ended up to be a Word document 5MB large and was sent without realising it. After that it was sent once more. This time as a PDF file... which happened to be 33MB large and was created using the Word document as a base. :-( Both mails went to 250+ recipients. The first mail did not kill the mailserver, the second did. :-( For exceptions like these I want to have a tool to catch them before it fills up the server. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 3:31 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 8:51 AM Subject: [Declude.JunkMail] large mail to large number op recips Hi, We are a school and: - sometimes someone needs to send a large e-mail (20-30 MB) to one of the staf or students. - several times a day we send e-mails to large groups of students so the BCC field might contain up to 1500 addresses. Both items are no problem until they are combined like some tried today. :-( Suddenly I lost around 15GB of diskspace on my ma
Re: [Declude.JunkMail] large mail to large number op recips
One other thing. PREWHITELIST OFF should have the same affect of allowing tests to be run (the default). It is PREWHITELIST ON I thin that was broken. Setting PREWHITELIST OFF will cause more load, but you can safely use that setting to have scripts always run. Matt Darin Cox wrote: Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the number of recipients in combination with this to perform a custom action like routing or deleting... or route it to a program alias that sends you an alert notification. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 9:46 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Nope, we don't want to go that way for ALL mail. We''ve got several options to upload files for several purpouses within our school. Our website has lot's of option for that but.. sometimes we want to send something as an attachment. In this case it was a newsletter for our staf which was supposed to be about 200-300 KB, we want those newsletters sent as attachment, not as a link. For some reason the newsletter ended up to be a Word document 5MB large and was sent without realising it. After that it was sent once more. This time as a PDF file... which happened to be 33MB large and was created using the Word document as a base. :-( Both mails went to 250+ recipients. The first mail did not kill the mailserver, the second did. :-( For exceptions like these I want to have a tool to catch them before it fills up the server. Met vriendelijke groet, Bonno Bloksma hoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhoven t 040 296 28 28 / f 040 237 35 20 [EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 3:31 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 8:51 AM Subject: [Declude.JunkMail] large mail to large number op recips Hi, We are a school and: - sometimes someone needs to send a large e-mail (20-30 MB) to one of the staf or students. - several times a day we send e-mails to large groups of students so the BCC field might contain up to 1500 addresses. Both items are no problem until they are combined like some tried today. :-( Suddenly I lost around 15GB of diskspace on my mailserver. At least that is what IMail tried because I only had about 10GB left on my mailbox drive. Guess what happened? Is there a way using Declude Junkmail to flag this situation and stopping the e-mail while still allowing the two items above? I'm currently using Declude 2.16, Junkmail Std and AV Pro. Met vriendelijke groet, Bonno Bloksma hoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhoven t 040 296 28 28 / f 040 237 35 20 [EMAIL PROTECTED] / www.tio.nl
Re: [Declude.JunkMail] large mail to large number op recips
You can write it in _vbscript_ and pass the recipients into the script with the argument %RECIPIENTS% Once you have the number of recipients (found by counting the @ symbols in that argument), you can then get the message size and do some multiplication. Here's one big issue though. If you whitelist your own users, as most of us do, this filter won't work, or at least it shouldn't work. There is a bug though introduced in 2.x that causes all tests to run despite the sender being whitelisted, but it will cause messages to still score 0 (just wastes resources). Therefore you might try just deleting or moving the message file with the script instead of filtering it with Declude. Matt Darin Cox wrote: Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the number of recipients in combination with this to perform a custom action like routing or deleting... or route it to a program alias that sends you an alert notification. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 9:46 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Nope, we don't want to go that way for ALL mail. We''ve got several options to upload files for several purpouses within our school. Our website has lot's of option for that but.. sometimes we want to send something as an attachment. In this case it was a newsletter for our staf which was supposed to be about 200-300 KB, we want those newsletters sent as attachment, not as a link. For some reason the newsletter ended up to be a Word document 5MB large and was sent without realising it. After that it was sent once more. This time as a PDF file... which happened to be 33MB large and was created using the Word document as a base. :-( Both mails went to 250+ recipients. The first mail did not kill the mailserver, the second did. :-( For exceptions like these I want to have a tool to catch them before it fills up the server. Met vriendelijke groet, Bonno Bloksma hoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhoven t 040 296 28 28 / f 040 237 35 20 [EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 3:31 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 8:51 AM Subject: [Declude.JunkMail] large mail to large number op recips Hi, We are a school and: - sometimes someone needs to send a large e-mail (20-30 MB) to one of the staf or students. - several times a day we send e-mails to large groups of students so the BCC field might contain up to 1500 addresses. Both items are no problem until they are combined like some tried today. :-( Suddenly I lost around 15GB of diskspace on my mailserver. At least that is what IMail tried because I only had about 10GB left on my mailbox drive. Guess what happened? Is there a way using Declude Junkmail to flag this situation and stopping the e-mail while still allowing the two items above? I'm currently using Declude 2.16, Junkmail Std and AV Pro. Met vriendelijke groet, Bonno Bloksma hoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhoven t 040 296 28 28 / f 040 237 35 20 [EMAIL PROTECTED] / www.tio.nl
Re: [Declude.JunkMail] large mail to large number op recips
Certainly not for all mail, just for these circumstances... but I understand you want to avoid situations where this is done accidentally. I think a couple of people had a size test, and you could key off of the number of recipients in combination with this to perform a custom action like routing or deleting... or route it to a program alias that sends you an alert notification. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 9:46 AM Subject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Nope, we don't want to go that way for ALL mail. We''ve got several options to upload files for several purpouses within our school. Our website has lot's of option for that but.. sometimes we want to send something as an attachment. In this case it was a newsletter for our staf which was supposed to be about 200-300 KB, we want those newsletters sent as attachment, not as a link. For some reason the newsletter ended up to be a Word document 5MB large and was sent without realising it. After that it was sent once more. This time as a PDF file... which happened to be 33MB large and was created using the Word document as a base. :-( Both mails went to 250+ recipients. The first mail did not kill the mailserver, the second did. :-( For exceptions like these I want to have a tool to catch them before it fills up the server. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 3:31 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 8:51 AM Subject: [Declude.JunkMail] large mail to large number op recips Hi, We are a school and: - sometimes someone needs to send a large e-mail (20-30 MB) to one of the staf or students. - several times a day we send e-mails to large groups of students so the BCC field might contain up to 1500 addresses. Both items are no problem until they are combined like some tried today. :-( Suddenly I lost around 15GB of diskspace on my mailserver. At least that is what IMail tried because I only had about 10GB left on my mailbox drive. Guess what happened? Is there a way using Declude Junkmail to flag this situation and stopping the e-mail while still allowing the two items above? I'm currently using Declude 2.16, Junkmail Std and AV Pro. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl
RE: [Declude.JunkMail] large mail to large number op recips
Could the Word files go in RTF format? Sometimes I find they are smaller, but still readable in Word. Feeling your pain, John C From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bonno BloksmaSent: Tuesday, February 14, 2006 8:47 AMTo: Declude.JunkMail@declude.comSubject: Re: [Declude.JunkMail] large mail to large number op recips Hi, Nope, we don't want to go that way for ALL mail. We''ve got several options to upload files for several purpouses within our school. Our website has lot's of option for that but.. sometimes we want to send something as an attachment. In this case it was a newsletter for our staf which was supposed to be about 200-300 KB, we want those newsletters sent as attachment, not as a link. For some reason the newsletter ended up to be a Word document 5MB large and was sent without realising it. After that it was sent once more. This time as a PDF file... which happened to be 33MB large and was created using the Word document as a base. :-( Both mails went to 250+ recipients. The first mail did not kill the mailserver, the second did. :-( For exceptions like these I want to have a tool to catch them before it fills up the server. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 3:31 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 8:51 AM Subject: [Declude.JunkMail] large mail to large number op recips Hi, We are a school and: - sometimes someone needs to send a large e-mail (20-30 MB) to one of the staf or students. - several times a day we send e-mails to large groups of students so the BCC field might contain up to 1500 addresses. Both items are no problem until they are combined like some tried today. :-( Suddenly I lost around 15GB of diskspace on my mailserver. At least that is what IMail tried because I only had about 10GB left on my mailbox drive. Guess what happened? Is there a way using Declude Junkmail to flag this situation and stopping the e-mail while still allowing the two items above? I'm currently using Declude 2.16, Junkmail Std and AV Pro. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl
RE: [Declude.JunkMail] large mail to large number op recips
Not knowing the contents or reasons for everyone getting the files, I'll say this: I fight similar user temptations at our school (380 staff / 5000 students). I lose sometimes, but what I (also being the webmaster) encourage is that large files be posted on the FTP server and a link is emailed to everyone. Also we have separate staff and student listservs (updated each night), so we don't have to worry if some office or dean has the latest list of students and staff and the BCC thing. Sorry, I realize this is not a direct answer to the question of how can Declude help, but is how we address the problem - not perfectly, but as best we can. John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bonno BloksmaSent: Tuesday, February 14, 2006 7:52 AMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] large mail to large number op recips Hi, We are a school and: - sometimes someone needs to send a large e-mail (20-30 MB) to one of the staf or students. - several times a day we send e-mails to large groups of students so the BCC field might contain up to 1500 addresses. Both items are no problem until they are combined like some tried today. :-( Suddenly I lost around 15GB of diskspace on my mailserver. At least that is what IMail tried because I only had about 10GB left on my mailbox drive. Guess what happened? Is there a way using Declude Junkmail to flag this situation and stopping the e-mail while still allowing the two items above? I'm currently using Declude 2.16, Junkmail Std and AV Pro. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl
Re: [Declude.JunkMail] large mail to large number op recips
Hi, Nope, we don't want to go that way for ALL mail. We''ve got several options to upload files for several purpouses within our school. Our website has lot's of option for that but.. sometimes we want to send something as an attachment. In this case it was a newsletter for our staf which was supposed to be about 200-300 KB, we want those newsletters sent as attachment, not as a link. For some reason the newsletter ended up to be a Word document 5MB large and was sent without realising it. After that it was sent once more. This time as a PDF file... which happened to be 33MB large and was created using the Word document as a base. :-( Both mails went to 250+ recipients. The first mail did not kill the mailserver, the second did. :-( For exceptions like these I want to have a tool to catch them before it fills up the server. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl - Original Message - From: Darin Cox To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 3:31 PM Subject: Re: [Declude.JunkMail] large mail to large number op recips How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 8:51 AM Subject: [Declude.JunkMail] large mail to large number op recips Hi, We are a school and: - sometimes someone needs to send a large e-mail (20-30 MB) to one of the staf or students. - several times a day we send e-mails to large groups of students so the BCC field might contain up to 1500 addresses. Both items are no problem until they are combined like some tried today. :-( Suddenly I lost around 15GB of diskspace on my mailserver. At least that is what IMail tried because I only had about 10GB left on my mailbox drive. Guess what happened? Is there a way using Declude Junkmail to flag this situation and stopping the e-mail while still allowing the two items above? I'm currently using Declude 2.16, Junkmail Std and AV Pro. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl
Re: [Declude.JunkMail] large mail to large number op recips
How about implementing a web-based upload/download site for this. I've done this for a couple of graphic design firms to allow their customers to upload files, which then sends the intended recipient an email notification with a link to download. Much, much more efficient than SMTP (mail encoding generally runs up the file size about 33% or so), faster, and much less network traffic in a distribution situation since many of the recipients will not download the file. Also doesn't hang the user's mailbox when sending/receiving for several minutes while uploading/downloading. Darin. - Original Message - From: Bonno Bloksma To: Declude.JunkMail@declude.com Sent: Tuesday, February 14, 2006 8:51 AM Subject: [Declude.JunkMail] large mail to large number op recips Hi, We are a school and: - sometimes someone needs to send a large e-mail (20-30 MB) to one of the staf or students. - several times a day we send e-mails to large groups of students so the BCC field might contain up to 1500 addresses. Both items are no problem until they are combined like some tried today. :-( Suddenly I lost around 15GB of diskspace on my mailserver. At least that is what IMail tried because I only had about 10GB left on my mailbox drive. Guess what happened? Is there a way using Declude Junkmail to flag this situation and stopping the e-mail while still allowing the two items above? I'm currently using Declude 2.16, Junkmail Std and AV Pro. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl
[Declude.JunkMail] large mail to large number op recips
Hi, We are a school and: - sometimes someone needs to send a large e-mail (20-30 MB) to one of the staf or students. - several times a day we send e-mails to large groups of students so the BCC field might contain up to 1500 addresses. Both items are no problem until they are combined like some tried today. :-( Suddenly I lost around 15GB of diskspace on my mailserver. At least that is what IMail tried because I only had about 10GB left on my mailbox drive. Guess what happened? Is there a way using Declude Junkmail to flag this situation and stopping the e-mail while still allowing the two items above? I'm currently using Declude 2.16, Junkmail Std and AV Pro. Met vriendelijke groet,Bonno Bloksmahoofd systeembeheer tio hogeschool hotelmanagement en toerisme begijnenhof 8-12 / 5611 el eindhovent 040 296 28 28 / f 040 237 35 20[EMAIL PROTECTED] / www.tio.nl
