[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Making Remailers Widespread [REMAILERS]
Bill Stewart <[email protected]> writes:
> >Unfortunately, one-way remailers have much fewer uses than two-way remailers
> >any many of these uses are abusive.
>
> I agree, it's a problem; the return address seems to reduce abuse.
It's not only a question of traceability... Most "useful" uses of Julf's
remailer involved scenarios like someone posting anonymously to a public
forum and soliciting replies, or someone contacting another party
anonymously and wanting to receive a reply. It was pretty easy for two
anonmous parties to establish a dialog. An optional reachable return address
(even if the sender can't be traced back and be punished for abuse) makes
the system so much more useful for things other than anonymous farting.
> >> - A centralized block list (e.g. http://www.remailer.net/block.txt)
> >> which all of the form-based remailers could load and reference would
> >> allow non-picky operators not to have to handle it themselves
> >A single centralized point of failure is bad. Maybe 4 or 5 redundant ones.
> >A blocking request sent to one will be replicated in the other automatically
>
> Good point. A bit tough to implement in a no-brainer out-of-the-box remailer
> you gain a bit by having the block list point to an address that's really
> a round-robin DNS spinner of some sort, but that still leaves you with
> centralization.
How about: maintain a list of trusted blocking-list sites (comparable to the
list of remailers used for chaining) and when it comes the time to update the
local copy of the blocking list, ask a random one on the list; if it's down,
ask another random one on the list. There may even be more than one list. :-)
> >> - special-case for "postmaster", who may want to block
> >> all of foo.domain instead of just [email protected]
> >> - special-special-case for postmasters of big sites, e.g. aol, net
> >> who we may want to ignore?
>
> >I don't think it's a good idea to suport blocking receivers in an entire
> >domain, like *@aol.com. Just say it's not supported.
>
> Blocking an entire domain like *@aol.com is mostly bad.
> Blocking an entire domain like *@myconsultingfirm.com is fine.
I think it's also bad, but I suppose the market wants it, so I'm showing
below how this can be done.
> >> - A sender-blocking list is harder, and may still take human attention
> >I don't think it's a good idea to support sender blocking at all.
>
> There are some spammers you'd like to stop quickly when a Spam Event
> is happening. There are broken email gateways that may need blocking.
> There are known abusers you might want stopped. And there are folks like
> [email protected] who can be presumed to be forgeries :-)
> A sender-blocking list administered by the Remailer Cabal* would be
> a reasonable default for no-brainer remailers, and obviously it
> should be possible for remailer-admins to override or ignore if they want.
With most ISP's it's trivial to forge one's From: header in SMTP.
Switching to another dime-a-dozen throwaway account is also trivial.
Just admit that you can't block senders, and don't pretend that you
can - false pretenses destroy one's credibility.
Timmy the pathological liar posted a rant a few weeks ago on how
"remailer operators can't be choose" - usually he's full of shit, but
that time he had a point - he must have plagiarized it.
> >Would the receiver blocking list be available to everyone to view? That
> >sounds like a violation of privacy. Someone suggested on this list that
> >(assuming that the entires are addresses that match exactly, not regular
> >expressions), one can store hashes of addresses.
>
> That's worth doing, or at least thinking about seriously.
> The most interesting regular expressions are *@domain (which you can
> handle by keeping separate block lists for domains and full addresses
> (or a merged list that the using remailer checks both)) and
> *@*.domain and user@*.domain - e.g. [email protected],
> which would successfully deliver mail to [email protected].
> Perhaps the system needs to keep two hashes - hash(alice),hash(big-isp.com)
> and check subsets of the domain name? This is creeping featurism,
> but it may be the right way to go to set a good precedent.
I think I see a way to accomplish this without too much trouble.
When an e-mail is directed at [email protected], the code that checks
for blocking will search for the following records in the blocking list:
[email protected] (exact match)
*@c4.c3.c2...c1 (replace user by *)
u@*.c3.c2...c1 (replace leftmost .-separated piece of domain by *)
*@*.c3.c2...c1 (both)
and repeat until there are only 2 components left in the domain name.
E.g., if a message is addressed to [email protected], the blocking
code would compute hashes of the following strings and check for each one's
presence in the blocked list:
[email protected]
*@under.bwalk.dm.com
dlv@*.bwalk.dm.com
*@*.bwalk.dm.com
dlv@*.dm.com
*@*.dm.com
and here we stop. This shouldn't take much more CPU time than the blocking
code in Lance Cotrell's mixmaster that I just looked at, which loops though
all blocking patterns and checks if each one matches.
Now, the question is, who would be allowed to add records containing
'*' to the blocking list using the cookie protocol? I suggest that it be
one of the contacts listed in Internic's database.
E.g. [email protected] can add himself to the blocking list using the
cookie protocol. If joe tries to add *@*.place.com to the blocking list,
the 'bot looks at Internic's database and sees only jim and jeff listed
for place.com, so it refuses. On the other hand, [email protected] can
add *@*.place.com, joe@*.place.com, etc, because Internet says he's the
admin for place.com.
Thus a blocking record for [email protected] could be added by
anyone listed in toad.com's Internic entry. There's no need for any
Remailer Cabal [tinc] to maintain blocking lists.
One other suggestion: instead of storing one bit of information (the
address is on the list or not), why not have several flag bits.
E.g., the blocking list could contain records similar to:
hash - e.g. 160-bit SHA
flags - e.g. reserve 32 bits
If the list is sorted by hash, then using binary search to check whether a
value is in it is very fast (much faster than matching wildcards). But at
the same time you can retrieve the flags word, which could be used, e.g.,
to say that an address doesn't wish to block all inciming anonymous
e-mail, but only e-mail that appears not to contain a reply block, or
whatever other preferences can be stuffed into 32 bits.
E.g., one could use 2 or 3 bits to specify the maximum size of a message
to be delivered to addresses matching this pattern: 000 for no limit,
and nnn for nnn*4K bytes.
> One unfortunate result of only using hashed names and not
> readable names is that it doesn't help the current remailer operators,
> since their existing code doesn't work that way.
This seems like a straightforward replacement for a small piece
of code in Lance Cotrell's mixmaster (which remains to be written, of
course :-). It's probably not hard to plug the same code into other
remailers if they're well-written.
---
<a href="mailto:[email protected]">Dr.Dimitri Vulis KOTM</a>
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps