I take this to mean my method of copying the contents of the message from Outlook Express's Properties>Details>Message Source window into a new message probably isn't helping you any, as I believe this does in fact "de-fang" the message?
Dave Strzemienski Centrivity Network Operations ----- Original Message ----- From: "Pete McNeil" <[EMAIL PROTECTED]> To: "Bonno Bloksma" <[EMAIL PROTECTED]> Sent: Tuesday, July 27, 2004 9:43 AM Subject: Re[2]: [sniffer] A few notes... > On Tuesday, July 27, 2004, 4:42:26 AM, Bonno wrote: > > BB> Hi, > > BB> [.....] > >> The spam@ address is ONLY for submitting spam that you wish to have > >> filtered. > > BB> About that.... I have been sending the occasional spam mails as an > BB> attachment, that way you have the full message including any headers. Is > BB> that indeed the preffered way? > > Yes, if it's easy for you to do. However the only data we will collect > from the headers in a submission to spam@ are: > > * Malformed headers that we can identify. > * IP data that we can verify automatically. > > Simply forwarding the spam will also work nicely though... > > In most cases we code for text, uri, and structures in the message > content so it is usually fine to simply forward spam to the spam@ > address. If you use TheBat! or another email client that supports > redirect then use that - because redirect also preserves the header > information and content. Avoid any forwarding process that rewrites > and/or "defangs" the message in any way. > > Submissions to spam _should_ be in their original condition, but that > is not strictly necessary. > > The reason for this is that submissions to spam@ are open and > therefore subject to abuse so our policies for processing these > messages are geared toward avoiding abuse and preventing false > positives. Some of these guidelines are: > > * spam@ submissions are anonymous - we do not respond to notes of any > kind that claim to be from anyone. > > * If we have any doubt about a spam@ submission we skip it. > > * We strongly consider that any submission to spam@ may be forged. > This is also true of false@ submissions which must be verified by the > license id and the sender's address plus (occasionally) the source IP. > > * If we cannot code a spam@ submission for everyone then we will not > code it. That means, if we suspect the possibility of a false positive > then we will ignore the submission. Our goal is for the core rulebase > to tag messages that all of our users will agree are unwanted (spam). > > --- If you have a chronic spam issue with a particular submission and > you suspect we have ignored it for some reason then please contact us > about it at our support@ address and request a local black rule. > Remember that our support@ address is filtered though - so if you send > us spam there we will not get the message. > > * If the message is garbled or modified in any way we may ignore it > unless we can explain the process and decipher the content. > > I hope this helps clear things up. > > For reference, spamtrap data follows an entirely different set of > rules because the process is automated and more tightly controlled. > For information on submitting spamtrap data please contact us off list > at [EMAIL PROTECTED] > > Thanks! > > _M > > > > This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html > This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
