The DCC can also collect hashes of IP addresses. At Paul Vixie's
suggestion, early versions could answer questions like "how many messages
with this body checksum had this source IP address?"
That's not what we want. We want to answer this question:
"Has the message with this checksum originated from more than X distinct
IP addresses in the last Y hours?"
This query lets you detect open-relay and proxy abusers.
Although it looks like the DCC servers have to collect the IP
information, they don't have to give it out. So the potential for
abuse is limited to the people who run the DCC servers, not to anyone
who can query them.
Please also consider the amount of data you are talking about. You
will probably collect 500 or 1000 bytes per mail message.
No; way less than this. For a mail message, we collect the body
checksum, the sending-IP checksum and maybe a few flags indicating
failed RCPT commands. At most 60-100 bytes/message.
If you sample 1% of mail, and accept my guess that's 100 M msgs/day,
you're talking about collecting and reducing 100 GBytes of data/day.
I'm thinking 10GB/day.
You're right; the current DCC scheme of flooding breaks down. So we
use a DNS-like approach. A network of DCC servers are responsible for
different portions of the checksum space. So if we're interested in
a message with checksum abcd1234..., the "root" DCC servers tell us which
servers collect statistics for the abcd... subspace. Within a given
subspace, you can use flooding for redundancy.
You'd need to
repeat your measurements every day for a week, because spam varies
during the data and during the week. You'd also want to repeat it
every few weeks to catch long term changes. Arithmetic gives numbers
that would need a serious source funds.
Or a more scalable architecture than flooding the database.
--
David.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg