From: "David F. Skoll" <dfs(_at_)roaringpenguin(_dot_)com>
...
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.
That's not an effective response to the privace issues. As I said,
that reasoning seemed almost ok when it was thought that DCC servers
would be run by one organization. The current, real life global
network of ~120 DCC servers already involves far more people and
organizations than I think can be trusted. It's not that any single
DCC server operator is untrustworthy, but that every group of 120 or
more people is untrustworthy.
...
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 I thought you knew how to make a single checksum that is fuzzy
enough to ignore "hashbusters" but not so fuzzy that it has false
positives, I'd ask you in private about it. I've spent years
thinking about that problem and listening to other people's ideas.
My imperfect current solution involves 3 checksums. A single naive
checksum would discover no two IP addresses ever send the same
message, except for trivial cases such as some virus warnings,
because its answers would all differ.
...
You're right; the current DCC scheme of flooding breaks down.
I suspect you don't understand it, because the DCC scheme of flooding
doesn't just break down for what you are talking about; it's irrelevant.
DCC serves database currently run at 100-400 MByte. The default
non-spam expiration for the cheksums in the databases averages 1.5
days. At 20 Mmsgs/day, that's 30 Msgs, or 1-4 bytes message. While
I'm a hopeless, old-school bit-fiddler, I can't cram 3 16-byte MD5
body checksums, flags, pointers, and the rest of the stuff needed for
a database into 1-4 bytes message.
...
Or a more scalable architecture than flooding the database.
While this mailing list is under the auspices of the IRTF, it should
not be used for unsupported wouldn't-it-be-nice-if speculation.
"Running code" often matters even IRTF lists. I've already said more
than I should have about the practicality what the proposal.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg