Pete McNeil wrote:
This may help:
http://kb.armresearch.com/index.php?title=Message_Sniffer.TechnicalDetails.GBUdb
I did read that first. It was helpful. I'll keep referring back.
We are developing an auto-drill-down feature for GBUdb to assist in
automatically training GBUdb in this way. The auto drill feature will
add IPs of intermediate systems to the local ignore list based on
header directives. The theory is that GBUdb will be able to
automatically learn to ignore the intermediate nodes of mixed-source
ISPs in order to identify the original source of the message.
There is still some development work to do on this experimental
feature but we hope to include it in the upcoming release. Any
insights you can provide on reliably identifying these intermediate
servers would be very useful.
I'm not confident that this will handle the "forwarded messages"
scenarios that I described, which I have ready custom programmed for the
specific narrow range of ways that this currently happens with my server.
Please share an example of the header you would inject.
Currently, I'm using the following:
X-RegEx-Original-IP: 127.0.0.1
(But "X-RegEx-Original-IP" was arbitrary. This was inherited by an
antiquated anti-spam utility I used years ago. The "X-RegEx-Original-IP"
part can change at any time. This would even be a header custom
designated by Sniffer.)
Even better, another option would be for the IP to be passed to sniffer
via the command line where sniffer would know to use that one and not
bother trying to grab this from the header. Please consider that as a
feature request.
It is not possible to turn off truncate on a message by message basis.
It is possible to turn off truncate for all messages but not on a
message by message basis.
that will suffice
Here is what I'd like to do which I believe would make my contribution
to sniffer most effective:
(A) Have sniffer NOT automatically input data into GBUdb with each
sniffer scan. (Is that possible?)
You could create "header directives" to selectively disable GBUdb
training.
You can also disable GBUdb training for all messages.
<training on-off='off'>
That will work. But will this disable the "SNFClient.exe -bad" and
"SNFClient.exe -good" tools?? and will this disable sharing of the data?
Can data accumulated via these manual reportings be shared even if
"training" is "off"?
That sounds very much like what these tools were designed for. However
the effect may not be what you intend.
If the IPs you track are not detected as the source IP by GBUdb then
it is likely to ignore the data during it's scans. It will evaluate
the statistics of the IP it believes to be the source. When it gets
that right it will find your data. When it gets that wrong it will
find no data (most likely) so GBUdb will be effectively inert in those
cases.
If your intent is simply to input this data into the GBUdb system so
that it is available as a resource then that will work - somewhat.
One other thought that I have is that you could use the command line
(or the ignore list) to mark the IPs on your internal white-list as
Infrastructure (ignore flag). This might effectively train GBUdb to
skip those IPs when finding the source of the message - and in any
case would render GBUdb inert for those IPs.
There are too many IPs on that whitelist (it might have been possible
were it not that many of these entries are massive blocks of IPs).
Follow-up question...
If, therefore, I cannot stop GBUdb-processing for a particular message,
but I turn off truncate for all messages, the way I see it, couldn't I
simply ignore the GBUdb reporting for some particular messages? (might
not be as efficient, but I'd get the same result I seek!) But in a case
where truncate is turned off, if GBUdb reports a message as spam, AND
content rules ALSO mark that message as spam, will the return code tell
me that both GBUdb *and *rules caught the spam? Or do I get one code
instead of the other (if so, which one?)
Thanks!
Rob McEwen
#############################################################
This message is sent to you because you are subscribed to
the mailing list <sniffer@sortmonster.com>.
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]>
