Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
>It is unclear - we receive FPs that have traveled through all sorts of >clients, quarantine systems, changed hands various numbers of times, >or not (to all of those)... Right now I don't want to make that >research project a high priority. Understood. >That's true it wouldn't change, but submitting the message directly >would not be correct - the dialogue is with you, and in any case, >additional trips through the mail server also modify parts of the >header and sometimes parts of the message (tag lines, disclaimers, >etc)... Hmmm... with attaching the original message, I guess it still makes more sense to deliver to us first for now. Just looking for an alternative that gets you the message as close as possible to the original form as possible. Maybe we'll write a script to copy and forward the D*.SMD file as an attachment to you for FPs at some point in the future. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
That would be great if you could add message rewriting. With the complete lack of response by Declude to support emails and the support list, they're going to lost most of us as customers as soon as someone comes out with am IMail/SmarterMail compatible product that has weighting and the array of tests and scriptable filters we've come to rely on. Darin. - Original Message - From: "Pete McNeil" <[EMAIL PROTECTED]> To: "Message Sniffer Community" Sent: Wednesday, June 07, 2006 4:09 PM Subject: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions Hello Matt, Wednesday, June 7, 2006, 3:37:36 PM, you wrote: > > Pete, > > An X-Header would be very, very nice to have. I understand the > issues related to waiting to see if something comes through, and > because of that, I would maybe suggest moving on your own. I've got it on the list to have a message rewriting option... it's just not as high as some others. I hadn't thought about the weight gating utility - though that seems like something that would be useful in general for external tests... "weightgate -5 %WEIGHT% 20 " 5 0 is executed if %WEIGHT% is in the range [-5,20] and the exit code of is returned. That seems like a pretty simple utility to knock out - perhaps I will ;-) Also, on the FP reporting links idea, that would break the process - it's important for us to see the message for many reasons, and it's important for the FP resolution process to be interactive. _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
>> Can I interpret this as email address and matching source IP are sufficient >> if the correct email address is used to submit? >Yes. Ok, so the answer to my original suggestion is yes. Great. > If not, do you have any suggestions on how you would like to see us > inserting the license ID in the D file? >To clarify, nothing should be inserted in the D file. The original >message should be attached as an RFC 822 attachment is as close to the >original form as possible. Uh, but the D file contains mime segments corresponding to attachments. >The license id, if included at all, should be in the subject line of >the submission message. Good. Subject line is easier and more reliable to parse out. Not that it's needed per the original question. Darin. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
Right... quotes are no good. That came to light in the context of passing long file names (with spaces); the 8.3 format would be preferred. I've designed my folder structure such that none of the folders had spaces in them; that just happened to be the way it turned out and I'm glad I stuck with it. Andrew. From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Wednesday, June 07, 2006 1:22 PMTo: Message Sniffer CommunitySubject: Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions Pete,Since the %WEIGHT% variable is added by Declude, it might make sense to have a qualifier instead of making the values space delimited. Errors in Declude could cause values to not be inserted, and not everyone will want to skip at a low weight. I haven't seen any bugs with %WEIGHT% since shortly after it was introduced, but you never know. I have seen some issues with other Declude inserted variables though.One other thing that I came across with the way that Declude calls external apps...you can't delimit the data with things like quotes. There is no mechanism for escaping a functional quote from a quote that should appear in the data that you pass to it...so don't use quotes as delimiters :)MattPete McNeil wrote: Hello Matt, Wednesday, June 7, 2006, 3:37:36 PM, you wrote: Pete, An X-Header would be very, very nice to have. I understand the issues related to waiting to see if something comes through, and because of that, I would maybe suggest moving on your own. I've got it on the list to have a message rewriting option... it's just not as high as some others. I hadn't thought about the weight gating utility - though that seems like something that would be useful in general for external tests... "weightgate -5 %WEIGHT% 20 " 5 0 is executed if %WEIGHT% is in the range [-5,20] and the exit code of is returned. That seems like a pretty simple utility to knock out - perhaps I will ;-) Also, on the FP reporting links idea, that would break the process - it's important for us to see the message for many reasons, and it's important for the FP resolution process to be interactive. _M
Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
Pete, Since the %WEIGHT% variable is added by Declude, it might make sense to have a qualifier instead of making the values space delimited. Errors in Declude could cause values to not be inserted, and not everyone will want to skip at a low weight. I haven't seen any bugs with %WEIGHT% since shortly after it was introduced, but you never know. I have seen some issues with other Declude inserted variables though. One other thing that I came across with the way that Declude calls external apps...you can't delimit the data with things like quotes. There is no mechanism for escaping a functional quote from a quote that should appear in the data that you pass to it...so don't use quotes as delimiters :) Matt Pete McNeil wrote: Hello Matt, Wednesday, June 7, 2006, 3:37:36 PM, you wrote: Pete, An X-Header would be very, very nice to have. I understand the issues related to waiting to see if something comes through, and because of that, I would maybe suggest moving on your own. I've got it on the list to have a message rewriting option... it's just not as high as some others. I hadn't thought about the weight gating utility - though that seems like something that would be useful in general for external tests... "weightgate -5 %WEIGHT% 20 " 5 0 is executed if %WEIGHT% is in the range [-5,20] and the exit code of is returned. That seems like a pretty simple utility to knock out - perhaps I will ;-) Also, on the FP reporting links idea, that would break the process - it's important for us to see the message for many reasons, and it's important for the FP resolution process to be interactive. _M
