You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Serge Knystautas <se...@lokitech.com> on 2003/06/16 19:50:28 UTC
Personal IP blacklists
This weekend spammers felt the need to send my James installation over
50,000 emails that they knew wouldn't get relayed. I'm thinking of
creating a db-based personal blacklist and was wondering if anybody has
thought of something similar.
I already am using the db for the message stores, so it's convenient
(for me) to have this as another table. Right now I have to edit
config.xml and restart James, which is therapeutic right now, but I'm
sure will get old.
Anyone try to do something similar?
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Personal IP blacklists
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Serge Knystautas" <se...@lokitech.com>
> This weekend spammers felt the need to send my James installation over
> 50,000 emails that they knew wouldn't get relayed. I'm thinking of
> creating a db-based personal blacklist and was wondering if anybody has
> thought of something similar.
It would be good to have a way to share the data, maybe via a public xml
file with a set dtd that is generated from the db.
>
> Anyone try to do something similar?
I am sure lot of folks. I don't block, but do mark mail as spam that comes
from 347 domains. A lot of mail is from few ip addresses so may be good to
mark mail as spam from specific domains as well as ip addresses.
Does anyone know of a way to get say the list of email marketing domains ?
I really don't care about opt-in emails and would be very interested in
having a comprehesive list of email marketing domains.
Harmeet
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Server statistics (was: Personal IP blacklists)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Most of what you want is in the logs, just not bucketed for real-time
querying.
> total incoming messages/(unit time)
<timestamp> INFO smtpserver: Successfully spooled mail from <SENDER> for
[<RECIPIENTS>]
> total incoming connections/(unit time)
<timestamp> INFO smtpserver: Connection from <domain> (<IP-Address>)
> total incoming bytes/(unit time)
This we don't do at the moment.
> total outgoing ... (the same three as above)
Two of the three are already in RemoteDelivery. Only size is missing.
> total volume of mail held in local mailboxes
See the AbstractStorageQuotaMatcher code for how to do that. One could add
a command to the remote manager to also return the figure for a mailbox.
> total volume of mail held in local spools
Same as above, since spools are currently mailboxes. That will change with
v3.
> ip addresses generating most of the traffic/(recent unit of time)
Could be inferred from the logs if we logged size.
> ip addresses generating most of the connections/(recent unit of time)
Already in the logs.
> local addresses receiving large quantities of mail
Could be inferred from the logs if we logged size.
> local addresses sending large quantities of mail
Same as above.
Again, most of this is already in the logs, except for size. What isn't
present is a real-time statistics system, such as I laid out earlier, which
you could view similarly to the /proc interface.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Personal IP blacklists
Posted by Serge Knystautas <se...@lokitech.com>.
Richard O. Hammer wrote:
> My dream SMTP server has a GUI reminiscent of the control room at a
> power plant, with gauges which show every parameter which might be
> important to the operator, and with valves to throttle or completely
> shut down any segment of the operation which seems to be getting out of
> hand.
I'm thinking web-based, but yeah, that would be nice.
> Parameters such as the following would have both gauges (and/or warning
> lights and whistles) and values (operator-settable limits):
>
> total incoming messages/(unit time)
1. This can be a simple mailet... just log the size and time (other
info?) of every message that comes through. Then have a reporting tool
to pull over some time period.
> total incoming connections/(unit time)
2. Hmm, this would need to tweak the SMTPHandler to do this.
> total incoming bytes/(unit time)
3. Same as #1
> total outgoing ... (the same three as above)
4. Perhaps just another mailet, this time though logging what goes
through the outgoing spool.
> total volume of mail held in local mailboxes
5. This would have to be (an expensive) query done ad-hoc. I can't see
maintaining that as meta data.
> total volume of mail held in local spools
6. Same as #5.
> ip addresses generating most of the traffic/(recent unit of time)
7. Relates to how #1 is logging and reporting. Shouldn't be too difficult.
> ip addresses generating most of the connections/(recent unit of time)
8. Same as #7.
> local addresses receiving large quantities of mail
9. Another type of mailet, this time in local delivery spool.
> local addresses sending large quantities of mail
10. Extra report on #9.
> Also, another approach, I would prefer to have the server return an
> error upon RCPT TO: <unknownJoe>, rather than accept the message as
> James does at present. I think Noel said there were plans to change
> this in an upcoming James.
11. Yes, I think that's something that's coming.
Most of this is only 1 logging mailet that could get plugged into a
number of spots in the different spools, and then you'd need a reporting
tool to read those logs and give you nice data. Someone had talked
about adopting a "standard" logging format for James, which might get
much of this done just by relying on existing reporting tools that
unstandard that log file format.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Server statistics (was: Personal IP blacklists)
Posted by Jason Webb <jw...@inovem.com>.
Cool! No worries then.
My preferred option would be to ship James with JMX turned off.
If you want it then turn it on - if to turn it on, then you asked for
it...
I shall start to think a bit more about what and how to control and
instrument James.
I would like to JMX James 3.0 rather than v2 mainly because v3 is in dev
and I may need to make some fairly serious changes to James internals.
Any comments on this?
Jason Webb
Director iNovem Ltd
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 18 June 2003 19:34
> To: James Developers List
> Subject: RE: Server statistics (was: Personal IP blacklists)
>
> Jason,
>
> I suggest to you that the JMX MBeans are orthogonal from authenticated
> user.
> Let's get JMX into James, and let me go talk to Avalon about helping
us
> lock
> out unauthorized users. In fact, they are voting today to give James
> Committers access to the components area of their CVS module.
>
> We won't release James with JMX until we've secured it, but lets get
the
> instrumentation part of the project going. Fair enough? :-)
>
> --- Noel
>
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: Wednesday, June 18, 2003 4:01
> To: 'James Developers List'
> Subject: RE: Server statistics (was: Personal IP blacklists)
>
>
> I'd still like to do this (give James real JMX usability), but I have
> one hang-up with the current Avalon implementation in that I need
Avalon
> to provide authentication which it currently doesn't do. Once this is
> done then I can start Mbean'ing up James properly for control. Without
> this I won't start any work as it would James a serious security hole.
>
> My eventual goal is to instrument James as completely as possible :)
> I have the JMX book and I am ready...
>
> -- Jason
>
> > -----Original Message-----
> > From: Noel J. Bergman [mailto:noel@devtech.com]
> > Sent: 18 June 2003 08:05
> > To: James Developers List
> > Subject: RE: Server statistics (was: Personal IP blacklists)
> >
> >
> > JMX is very conceptually compatible with the ad hoc approach
> > Jason and I had discussed last summer. Remember what I said
> > about using a statistics object and a registry? From the JMX
> > specification: "The MBean server is a registry for MBeans [in
> > the application.]" Very similar concepts. Not that I would
> > claim uniqueness. SNMP, /proc, and other schemes are all in
> > the same pattern.
> >
> > JMX is the right way to do this for James, since it is a
> > standard, provides control, is embedded in Phoenix, is
> > growing in use, and provides a replacement for the aging
> > remote manager interface.
> >
> > > I imagine that the class doing the work would have a variable
which
> > > holds the statistic we care about.
> >
> > Classes. Plural. Lots of beans. :-)
> >
> > > This would cause SMTPHandler to refuse or defer some incoming
> > > connections.
> >
> > Minor nit, but this is wrong. You need to understand the
> > archtectural relationships between some of the components.
> > The protocol handler is used after a new connection is
> > established. Rejecting a new connection based upon busy
> > state would happen elsewhere.
> >
> > As I've said before, please feel free to contribute. If
> > you're interested in working on JMX for James, got for it. :-)
> >
> > Avalon has been using http://mx4j.sourceforge.net/.
> >
> > --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Server statistics (was: Personal IP blacklists)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jason,
I suggest to you that the JMX MBeans are orthogonal from authenticated user.
Let's get JMX into James, and let me go talk to Avalon about helping us lock
out unauthorized users. In fact, they are voting today to give James
Committers access to the components area of their CVS module.
We won't release James with JMX until we've secured it, but lets get the
instrumentation part of the project going. Fair enough? :-)
--- Noel
-----Original Message-----
From: Jason Webb [mailto:jw@inovem.com]
Sent: Wednesday, June 18, 2003 4:01
To: 'James Developers List'
Subject: RE: Server statistics (was: Personal IP blacklists)
I'd still like to do this (give James real JMX usability), but I have
one hang-up with the current Avalon implementation in that I need Avalon
to provide authentication which it currently doesn't do. Once this is
done then I can start Mbean'ing up James properly for control. Without
this I won't start any work as it would James a serious security hole.
My eventual goal is to instrument James as completely as possible :)
I have the JMX book and I am ready...
-- Jason
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 18 June 2003 08:05
> To: James Developers List
> Subject: RE: Server statistics (was: Personal IP blacklists)
>
>
> JMX is very conceptually compatible with the ad hoc approach
> Jason and I had discussed last summer. Remember what I said
> about using a statistics object and a registry? From the JMX
> specification: "The MBean server is a registry for MBeans [in
> the application.]" Very similar concepts. Not that I would
> claim uniqueness. SNMP, /proc, and other schemes are all in
> the same pattern.
>
> JMX is the right way to do this for James, since it is a
> standard, provides control, is embedded in Phoenix, is
> growing in use, and provides a replacement for the aging
> remote manager interface.
>
> > I imagine that the class doing the work would have a variable which
> > holds the statistic we care about.
>
> Classes. Plural. Lots of beans. :-)
>
> > This would cause SMTPHandler to refuse or defer some incoming
> > connections.
>
> Minor nit, but this is wrong. You need to understand the
> archtectural relationships between some of the components.
> The protocol handler is used after a new connection is
> established. Rejecting a new connection based upon busy
> state would happen elsewhere.
>
> As I've said before, please feel free to contribute. If
> you're interested in working on JMX for James, got for it. :-)
>
> Avalon has been using http://mx4j.sourceforge.net/.
>
> --- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Server statistics (was: Personal IP blacklists)
Posted by Jason Webb <jw...@inovem.com>.
I'd still like to do this (give James real JMX usability), but I have
one hang-up with the current Avalon implementation in that I need Avalon
to provide authentication which it currently doesn't do. Once this is
done then I can start Mbean'ing up James properly for control. Without
this I won't start any work as it would James a serious security hole.
My eventual goal is to instrument James as completely as possible :)
I have the JMX book and I am ready...
-- Jason
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 18 June 2003 08:05
> To: James Developers List
> Subject: RE: Server statistics (was: Personal IP blacklists)
>
>
> JMX is very conceptually compatible with the ad hoc approach
> Jason and I had discussed last summer. Remember what I said
> about using a statistics object and a registry? From the JMX
> specification: "The MBean server is a registry for MBeans [in
> the application.]" Very similar concepts. Not that I would
> claim uniqueness. SNMP, /proc, and other schemes are all in
> the same pattern.
>
> JMX is the right way to do this for James, since it is a
> standard, provides control, is embedded in Phoenix, is
> growing in use, and provides a replacement for the aging
> remote manager interface.
>
> > I imagine that the class doing the work would have a variable which
> > holds the statistic we care about.
>
> Classes. Plural. Lots of beans. :-)
>
> > This would cause SMTPHandler to refuse or defer some incoming
> > connections.
>
> Minor nit, but this is wrong. You need to understand the
> archtectural relationships between some of the components.
> The protocol handler is used after a new connection is
> established. Rejecting a new connection based upon busy
> state would happen elsewhere.
>
> As I've said before, please feel free to contribute. If
> you're interested in working on JMX for James, got for it. :-)
>
> Avalon has been using http://mx4j.sourceforge.net/.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Server statistics (was: Personal IP blacklists)
Posted by "Noel J. Bergman" <no...@devtech.com>.
JMX is very conceptually compatible with the ad hoc approach Jason and I had
discussed last summer. Remember what I said about using a statistics object
and a registry? From the JMX specification: "The MBean server is a registry
for MBeans [in the application.]" Very similar concepts. Not that I would
claim uniqueness. SNMP, /proc, and other schemes are all in the same
pattern.
JMX is the right way to do this for James, since it is a standard, provides
control, is embedded in Phoenix, is growing in use, and provides a
replacement for the aging remote manager interface.
> I imagine that the class doing the work would have a variable which
> holds the statistic we care about.
Classes. Plural. Lots of beans. :-)
> This would cause SMTPHandler to refuse or defer some incoming
> connections.
Minor nit, but this is wrong. You need to understand the archtectural
relationships between some of the components. The protocol handler is used
after a new connection is established. Rejecting a new connection based
upon busy state would happen elsewhere.
As I've said before, please feel free to contribute. If you're interested
in working on JMX for James, got for it. :-)
Avalon has been using http://mx4j.sourceforge.net/.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Server statistics (was: Personal IP blacklists)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Note that on its face JMX is a services framework similar to avalon but with
less cruft and without the compiler-time checks (for better or worse). My
stuff is a JMX SMTP Service for Jboss + later I'll do POP, IMAP and
Exchange...
If you know who I am, you know I'm the guy to do such a crackheaded thing.
-Andy
On 6/16/03 5:45 PM, "Richard O. Hammer" <RO...@EarthLink.net> wrote:
> A week or more ago on this list I saw mention of JMX
> <http://java.sun.com/products/JavaManagement/>, though I did not pay
> close attention to that thread, so perhaps I'm repeating something
> here. I've read the first 15% of the JMX spec, and I have the
> impression that JMX is intended for uses such as monitoring server
> statistics and setting server control parameters, such as number of
> incoming connections per unit time and others which I listed earlier.
>
> I imagine that the class doing the work would have a variable which
> holds the statistic we care about. For instance SMTPHandler might
> keep an int connectionsDuringLastMinute, which value could be sampled
> and displayed on a little gauge like the temperature gauge on the
> dashboard of my car.
>
> Similarly, that class could have a control variable, an int
> connectionsPerMinuteLimit, which the administrator could set, if
> needed, with a knob (or the best GUI equivalent) right under the
> gauge. This would cause SMTPHandler to refuse or defer some incoming
> connections.
>
> That class might also keep a SortedSet of the IP addresses currently
> sending in the most mail, giving the administrator ability to limit
> the incoming rate from any given IP, just as easy as closing one of
> the windows a little bit in a car with electric windows.
>
> Logging comes to us from an age before GUIs. It still serves some
> purposes well, but, for managing current, ongoing problems, much
> better pictures and real-time controls are within reach (hopefully
> speaking).
>
> Anyhow, do others think of JMX as useful for such monitoring and control?
>
> Rich
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
--
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi
For Java and Excel, Got POI?
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Server statistics (was: Personal IP blacklists)
Posted by Steve Brewin <sb...@synsys.com>.
> -----Original Message-----
> From: Richard O. Hammer [mailto:ROHammer@EarthLink.net]
> Sent: 16 June 2003 22:46
> To: James Developers List
> Subject: Re: Server statistics (was: Personal IP blacklists)
>
>
> A week or more ago on this list I saw mention of JMX
> <http://java.sun.com/products/JavaManagement/>, though I did not pay
> close attention to that thread, so perhaps I'm repeating something
> here. I've read the first 15% of the JMX spec, and I have the
> impression that JMX is intended for uses such as monitoring server
> statistics and setting server control parameters, such as number of
> incoming connections per unit time and others which I listed earlier.
>
JMX is a greatly enhanced, Java flavoured version of SNMP. It really is the
way to go for publishing server-side statistics in a Java environment. These
statistics can then be viewed in any JMX enabled tool, or using a JMX to
SNMP bridge, an SNMP tool. All enterprise class monitoring tools watch SNMP
statistics, a few speak JMX. Some J2EE app. servers include JMX monitors and
Sun has a reference implementation.
It is hard to see why any effort aimed at producing a range of James server
stats. should be doing anything other than publishing them via JMX. Maybe
open-source JMX monitors exist? I don't know, but leveraging or developing
one would be better than developing a James specific monitoring tool.
-- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Server statistics (was: Personal IP blacklists)
Posted by "Richard O. Hammer" <RO...@EarthLink.net>.
A week or more ago on this list I saw mention of JMX
<http://java.sun.com/products/JavaManagement/>, though I did not pay
close attention to that thread, so perhaps I'm repeating something
here. I've read the first 15% of the JMX spec, and I have the
impression that JMX is intended for uses such as monitoring server
statistics and setting server control parameters, such as number of
incoming connections per unit time and others which I listed earlier.
I imagine that the class doing the work would have a variable which
holds the statistic we care about. For instance SMTPHandler might
keep an int connectionsDuringLastMinute, which value could be sampled
and displayed on a little gauge like the temperature gauge on the
dashboard of my car.
Similarly, that class could have a control variable, an int
connectionsPerMinuteLimit, which the administrator could set, if
needed, with a knob (or the best GUI equivalent) right under the
gauge. This would cause SMTPHandler to refuse or defer some incoming
connections.
That class might also keep a SortedSet of the IP addresses currently
sending in the most mail, giving the administrator ability to limit
the incoming rate from any given IP, just as easy as closing one of
the windows a little bit in a car with electric windows.
Logging comes to us from an age before GUIs. It still serves some
purposes well, but, for managing current, ongoing problems, much
better pictures and real-time controls are within reach (hopefully
speaking).
Anyhow, do others think of JMX as useful for such monitoring and control?
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Server statistics (was: Personal IP blacklists)
Posted by "Noel J. Bergman" <no...@devtech.com>.
This topic just came up, again, in james-user last week
(http://archives.apache.org/eyebrowse/ReadMsg?listId=21&msgNo=6059), and is
related to a discussion from last summer
(http://archives.apache.org/eyebrowse/BrowseList?listName=james-dev@jakarta.
apache.org&by=thread&from=225096). If you want to skip other discussion,
you could go directly to
http://archives.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apac
he.org&msgNo=4076.
Perhaps you, Chris, Steve, Jason and others would like to work on it?
--- Noel
-----Original Message-----
From: Richard O. Hammer [mailto:ROHammer@EarthLink.net]
Sent: Monday, June 16, 2003 14:57
To: James Developers List
Subject: Re: Personal IP blacklists
My dream SMTP server has a GUI reminiscent of the control room at a
power plant, with gauges which show every parameter which might be
important to the operator, and with valves to throttle or completely
shut down any segment of the operation which seems to be getting out
of hand.
Parameters such as the following would have both gauges (and/or
warning lights and whistles) and values (operator-settable limits):
total incoming messages/(unit time)
total incoming connections/(unit time)
total incoming bytes/(unit time)
total outgoing ... (the same three as above)
total volume of mail held in local mailboxes
total volume of mail held in local spools
ip addresses generating most of the traffic/(recent unit of time)
ip addresses generating most of the connections/(recent unit of time)
local addresses receiving large quantities of mail
local addresses sending large quantities of mail
Also, another approach, I would prefer to have the server return an
error upon RCPT TO: <unknownJoe>, rather than accept the message as
James does at present. I think Noel said there were plans to change
this in an upcoming James.
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Personal IP blacklists
Posted by "Richard O. Hammer" <RO...@EarthLink.net>.
My dream SMTP server has a GUI reminiscent of the control room at a
power plant, with gauges which show every parameter which might be
important to the operator, and with valves to throttle or completely
shut down any segment of the operation which seems to be getting out
of hand.
Parameters such as the following would have both gauges (and/or
warning lights and whistles) and values (operator-settable limits):
total incoming messages/(unit time)
total incoming connections/(unit time)
total incoming bytes/(unit time)
total outgoing ... (the same three as above)
total volume of mail held in local mailboxes
total volume of mail held in local spools
ip addresses generating most of the traffic/(recent unit of time)
ip addresses generating most of the connections/(recent unit of time)
local addresses receiving large quantities of mail
local addresses sending large quantities of mail
Also, another approach, I would prefer to have the server return an
error upon RCPT TO: <unknownJoe>, rather than accept the message as
James does at present. I think Noel said there were plans to change
this in an upcoming James.
Rich
Serge Knystautas wrote:
> This weekend spammers felt the need to send my James installation over
> 50,000 emails that they knew wouldn't get relayed. I'm thinking of
> creating a db-based personal blacklist and was wondering if anybody has
> thought of something similar.
>
> I already am using the db for the message stores, so it's convenient
> (for me) to have this as another table. Right now I have to edit
> config.xml and restart James, which is therapeutic right now, but I'm
> sure will get old.
>
> Anyone try to do something similar?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Personal IP blacklists
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I've already got the database open, so I'd rather keep all the relative
> info there.
You also have the DNS available, and I suspect that it might be quicker
(actually, if I correctly recall my benchmarks from before, forget the
"might" part).
> And actually, in the back of my mind, I've been thinking about how to
> make these personal blacklists sharable... kinda a napster-blacklist.
DNS RBLs are sharable (obviously).
> But anyway, what it did lead me to was the idea of having the blacklist
> matcher point at the *message store*. As spam fills my spam folder,
> when it was something I wanted to blacklist, I would copy it from my
> spam store to my blacklist store. Then the matcher would look for any
> messages from the sending IP address in this blacklist store
Major performance issue. However, a service could periodically poll a
message store, and populate a block list.
That sort of service could resolve some other issues, e.g., another
derivation of the same abstract service could periodically poll a
"reprocess" folder, and insert those messages back into the queue. Take a
look at FetchScheduler, and perhaps abstract from there.
> This also preserves the evidence for why I blacklist them.
Maintaining the spam/evidence database is certainly worth doing. But for
publishing the block list, itself, I would suggest the DNS RBL approach.
FWIW, we can fairly easily integrate block listing into the fast-fail code.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Personal IP blacklists
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> It would be very simple to code a JDBC based block list matcher, but why
> don't you simply create a local DNS zone, and populate the zone file?
I've already got the database open, so I'd rather keep all the relative
info there.
And actually, in the back of my mind, I've been thinking about how to
make these personal blacklists sharable... kinda a napster-blacklist.
But anyway, what it did lead me to was the idea of having the blacklist
matcher point at the *message store*. As spam fills my spam folder,
when it was something I wanted to blacklist, I would copy it from my
spam store to my blacklist store. Then the matcher would look for any
messages from the sending IP address in this blacklist store, and if so,
would say "leave me alone, you already sent me 4,230 messages on June
12th". This also preserves the evidence for why I blacklist them.
Yes, I'm probably overthinking this, which was why I was wondering what
people's experience was with blacklisting IP addresses in general. I
also am finding that for certain spammers, they seem to have a full
C-class available to them, so I end up just blocking that last octet.
My blacklist store wouldn't handle that (just yet).
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Personal IP blacklists
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
It would be very simple to code a JDBC based block list matcher, but why
don't you simply create a local DNS zone, and populate the zone file?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org