Subject: RE: [Asrg] Random thought

From: "Sauer, Damon" <[email-masked]>
Date: Wed, 12 Mar 2003 13:03:21 -0500

-----Original Message-----
From: Jason Hihn [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 11:42 AM
To: ASRG
Subject: [Asrg] Random thought

What if we assigned a bucket in the email address?

joe[spam]@paytimepayroll.com

Consent expression is then indicated by the bucket [spam]
So if I wanted to give a contest (to win a BMW) my email (because they
require it) my email, I'd on the fly assign BMW's email to their own bucket,
I can specify joe[bmw] when registering to win a BMW on a website.

Then, my mail client can give it it's own folder, or swash it into a default
inbox according to my rules. It can create folders as it sees email (or if
spammers abuse it, we can manually set up a folder, and trash anything not
going to that folder)

The big problem is that [bucket] can be stripped off. So solve this problem
joe@ is to be considered invalid. Some bucket must be specified.
joe[default] would be one such example(though poorly choosen) Or joe could
set his [BMW] bucket to be his default inbox in his mail client.

This will also allow us to track who sells our info. If I start getting mail
sent to the BMW bucket and not from the sponsors, I know they sold my info.
After the contest, I can trash anything automatically sent to that bucket.

This makes evading spam rather easily, while still retaining your email
server and provider.

Comments?

 I think this could also be accomplished using an X-headers if you are not
trying to authenticate the address at the gateway.
This would be an administrative nightmare for x500 and Microsoft Exchange as
this is not programmatic and each [bucket] would have to be added manually.
One the other hand, I do not see an issue with writing a script that would
allow the user to assign themselves [buckets] but their email would not work
until the buckets were defined

 I think that this is an interesting approach and could likely be
implemented right away.

 I would start by writing an instruction on how each user can add rules to
their Microsoft Outlook client that would say, if TO: is user[bucket] then
place in X folder.
I would set up an internal webpage to define the buckets and
programmatically add these as secondary addresses to the users address list
via ldap mods.
I would set aside several thousands of dollars to replace business cards and
stationary.
I would have to define rules to remove old [bucket] addresses as they are
abandoned because spammers finally figured out what the address was.

 Hey, wouldn't it just be easier to assign multiple SMTP addresses?

 You see where I am going with this?

Regards,
Damon

*****
"The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from all
computers."
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Jason Hihn <[email-masked]>
Date: Wed, 12 Mar 2003 13:11:53 -0500

So close, yet so far. See interjected comments

> From: Sauer, Damon [mailto:[email-masked]]
> Sent: Wednesday, March 12, 2003 1:03 PM
> To: 'Jason Hihn'; ASRG
> Subject: RE: [Asrg] Random thought
>
>
....
>  I think that this is an interesting approach and could likely be

Indeed. The change is small, particularly of you rely on client-side
filtering alone.
Server-side you need only to trim [whatever] off the email for finding out
who to deliver to. A better implementation would be to have the server place
it in a folder on the server until retrieval.

> their Microsoft Outlook client that would say, if TO: is user[bucket] then

Exactly! But I'd still prefer the server to do it because as I've stated
before, Joe Blow knows nothing of filters.

> I would set up an internal web page to define the buckets and

Easily done, and relatively user-friendly

> abandoned because spammers finally figured out what the address was.

Now you're just getting crazy.

>  Hey, wouldn't it just be easier to assign multiple SMTP addresses?

We do, but the ad-hoc nature is key. "Assigning multiple SMPT addresses"
pins you down to a rather fixed list, and that's easy for a spammer to lock
on to, and that's not what I want. I go to great lengths to protect my email
addresses, but I always wind up getting on lists, then getting off is
impossible.

>  You see where I am going with this?

No.

---

From: Jason Hihn <[email-masked]>
Date: Wed, 12 Mar 2003 14:28:01 -0500

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.