Henrik K wrote:
Ok, while DNS would allow that, it would be a real waste of a
protocol. Why would you want to make the sending party wait for a
response that only adds delays and has no purpose? Simply send a UDP
packet and be done with it. No TCP or DNS overhead. One or two lines
of perl.
Marc Perkel wrote:
spam 1.2.3.4 example.com
ham 5.6.7.8 example2.com
Sending these one line TCP messages if fairly easy.
Why use TCP for this? Establishing a connection channel for simple short
mesages where a return code is not required introduces pointless overhead.
It'd be much
Jason Haar wrote:
Then the third filed is NONE. That's how I do it. But the idea is that
any kind of daya can be collectively gathered and distributed.
Instead of a TCP channel (which means software), what about using DNS?
If the SA clients did RBL lookups that contained the details as
Per Jessen wrote:
DNS lookups are usually tried done with UDP first,
Sure, DNS usually uses UDP, but the DNS resolver also waits for an
answer, wich is simply a waste of time when the sender doesn't need the
answer.
Add to this that resolving one address may result in multiple queries
On 12/19/2009 04:51 AM, Jonas Eckerman wrote:
(And if more security is needed the easiest way would be to simple
limit access to approved IP addresses.)
Except that a token would enable one owner with multiple SA instances
on separate networks to come across as one entity - that could be
On Sat, 19 Dec 2009, Jason Haar wrote:
On 12/19/2009 04:51 AM, Jonas Eckerman wrote:
(And if more security is needed the easiest way would be to simple
limit access to approved IP addresses.)
Except that a token would enable one owner with multiple SA instances
on separate networks to come
Jason Haar wrote:
On 12/17/2009 03:30 PM, Marc Perkel wrote:
Then the third filed is NONE. That's how I do it. But the idea is
that any kind of daya can be collectively gathered and distributed.
Instead of a TCP channel (which means software), what about using DNS?
If the SA clients did
On 12/18/2009 05:31 AM, Marc Perkel wrote:
In this case the idea is to gather data in real time. So those who
gather data need to be able to send the data to a central place that
receives the data and then makes it available to everyone.
You've lost me there - DNS would allow you to do that.
On Fri, Dec 18, 2009 at 08:20:47AM +1300, Jason Haar wrote:
On 12/18/2009 05:31 AM, Marc Perkel wrote:
In this case the idea is to gather data in real time. So those who
gather data need to be able to send the data to a central place that
receives the data and then makes it available to
On 16/12/2009 15:37, Marc Perkel wrote:
I have an idea for a cooperative data gathering project and it's similar
to what we at Junk Email Filter are doing internally. The idea to that a
number of you on the list who run a large spam filtering operation send
one line messages reporting IP
Mike Cardwell wrote:
On 16/12/2009 15:37, Marc Perkel wrote:
I have an idea for a cooperative data gathering project and it's similar
to what we at Junk Email Filter are doing internally. The idea to that a
number of you on the list who run a large spam filtering operation send
one line
marc,
what if there is no RDNS ?
;-)
- rh
Then the third filed is NONE. That's how I do it. But the idea is that
any kind of daya can be collectively gathered and distributed.
R-Elists wrote:
marc,
what if there is no RDNS ?
;-)
- rh
On 12/17/2009 03:30 PM, Marc Perkel wrote:
Then the third filed is NONE. That's how I do it. But the idea is that
any kind of daya can be collectively gathered and distributed.
Instead of a TCP channel (which means software), what about using DNS?
If the SA clients did RBL lookups that
Jason Haar wrote:
On 12/17/2009 03:30 PM, Marc Perkel wrote:
Then the third filed is NONE. That's how I do it. But the idea is
that any kind of daya can be collectively gathered and distributed.
Instead of a TCP channel (which means software), what about using DNS?
If the SA clients did RBL
15 matches
Mail list logo
