|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: Policy Server Protocol - Enhancement Request #1
From: Ronald F. Guilmette (rfg
monkeys.com)
Date: Fri Dec 01 2006 - 17:43:37 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
In message <4570B4C1.8020709
free.fr>, mouss
netoyen.net wrote:
>Ronald F. Guilmette wrote:
>> [snip]
>> Both parts of this overall task would be greatly facilitated by the ability
>> to pass certain mail message headers from the current (incoming) message
>> from Postfix to the external policy server.
>>
>
>The policy server mechanism is mostly for doing access control based on
>envelope.
Yes. I noticed.
>if you want to check data, then you should use a content
>filter (possibly as a proxy_filter to be able to reject the transaction).
Well, yes. That's definitely one way to do it.
But does that allow me to do all of the magically sorts of things that,
it appears, I could do with a policy server? In particular, will it allow
me to do a REJECT at any step in the SMTP protocol?
>a look at spamassassin rules shows that trying to do such analysis is at
>least a hard problem...
Yes. It is difficult to accurately differentiate automatically-generated
response message from all others.
But I do not need to achieve 100.0% accuracy. If I can get upwards of
99% accuracy... and I believe that I already can and have (in an un-
released tool that I have constructed here)... then that's more than
good enough for my purposes.
Once upon a time, vicious and vindictive spammers made it a point to try
to flood me with backscatter. That was a few years ago. I still do get
some backscatter on an almost daily basis, but probably no more than
anybody else who has a valid (and long-existing) e-mail address these
days. Still, whatever backscatter I _do_ continue to receive uses up
my valuable time. If I could kill off 99% of that stuff, then that would
be useful, and I would feel at least somewhat protected from the _next_
vicious mailbomb-by-backscatter attack, if it ever comes. (In fact I
already _can_ correctly detect > 99.9% of this stuff. I just can't yet
do it while also allowing in the "solicited" automated responses/bounces
that I actually _want_ to receive. But I'm working on that.)
>maybe you could explain how you would detect backscatter without talking
>of implementation.
I'm sorry. I don't understand your question. You want me to talk about
my code without talking about my code?
I don't have any real idea what you are asking for, however here's a copy
of the current "patterns" file that I'm currently using with the little
tool (mbf - Mail Backscatter Filter) that I've constructed:
http://www.monkeys.com/backscatter.txt
but I'm continuing to refine and extend this set of patterns, even as we
speak, and by this time tomorrow, there are likely to be 50+ more lines
in that file. In other words please DO NOT either think of or treat that
file as being in any sense "final" or complete. It's just a snapshot of
a file that is quite definitely still a work in progress, *AND* I will
*NOT* be updating the copy of this file whose URL is given above. No
warranty express or implied. Use at your own risk. Insertion of batteries
backwards will void your warranty. Void where prohibited by law. And oh
yes, that file is copyrighted, by the way. (Is that about enough legal
disclaimers? I hope so.)
Oh, and in case you were wondering, each non-comment (#) line in that file
contains an EXACT TEXT PREFIX. If the content of any such line match
exactly with the leftmost `n' bytes of any given mail message header,
where `n' is the length in bytes of the given line, then my little "mbf"
tool will call the message an automated response message. Eleswise, mbf
will call the message a non-automated-response message.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]