If we just blindly strip [bucket]s out (and concat their contents), then we
can be even more evasive:
j[realmail]hihn, [realmail]jhihn, [real]jhihn[mail], all of which result in
delivery to the jhihn mailbox, 'work' folder.
This starts to get a little more complex, because here I say that we can now
reject mail if the location of the bucket regions is not correct. This is
merely to offset a brute-force address guessing attack from a spammer. It
may be too complicated (particularly right now) to do, but it is something
to be thought about.
The down side is stupid spammers may generate more traffic trying to guess
the hash, but this in turns comes back at them: if they are to make 3
guesses, takes them 3x as long to reach the same number of people, with
lower chances when bucketing is implemented.
I am merely trying to use a hash that if there is not a collision (valid
bucket) the mail is dropped. We can then give out temporarily valid buckets,
and then revoke them. It also allows for leakage tracking, as described in
my first message of this thread. I suspect several people will be less privy
to leakage if you can prove they leaked it. Right now there is no
accountability.
Also, client-side filtering will allow me to aggregate buckets, by
specifying the same destination folder, incase I want a unified inbox
(several buckets empty into one). I can always separate out later as well.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg