Subject: [Asrg] 6. Proposals - Creative Addressing

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 02 Oct 2003 14:02:38 -0400

The ASRG has been asked to comment on the following draft:

http://www.ietf.org/internet-drafts/draft-kularski-spam-spamreduce-05.txt

Abstract:

"
    This document gives instructions for implementing a mail system that
    will reduce the amount of SPAM received by the end users. The
    instructions specify disposable and single-purpose mailboxes that
    will allow for the source of SPAM to be easily identified.
"

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Markus Stumpf <[email-masked]>
Date: Thu, 2 Oct 2003 21:41:49 +0200

>    will allow for the source of SPAM to be easily identified.

- '*' records in DNS are really bad.
  If spammers spoof the source address like in
      @joe.example.com
  attacked MTAs can easily block @joe.example.com.
  If there is a '*' RR as in
     *.example.com  MX 100 mail.example.com.
  they can use
     @qrwepuiqergqre.example.com
  and the only chance to block them is to block example.com as a whole.

- most MTA (at least qmail, postfix, sendmail and IMHO exim, also)
  provide for user extensions, so
     [email-masked]
  can also have full control ober all addresses like
     [email-masked]
     [email-masked]
     [email-masked]
  Look at my From: line for an example. I - and many others - use this
  for years and I have a [email-masked] catchall. If I have to
  leave an email address somewhere on the net I always use
     [email-masked]
  which makes it easy to track and easy to block.

- this is not of big value for spam prevention and tracking any more.
  I've seen attacks that clearly had my "[email-masked]" address
  as source of the harvesters that sent a bulk for
      [email-masked]
      [email-masked]
      [email-masked]
      [email-masked]
  and I've seen attacks with fresh addresses like
      [email-masked]
  that started about 3 days after the webpage went online and that
  *only* went to [email-masked] (no spam to [email-masked] before).

- the most useful part of the draft is probably 4.-7.

- overall the draft IMHO has too less "beef" to be helpful in general.
  And in will in no way reduce spam.

	\Maex
      
-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 02 Oct 2003 15:49:47 -0400

>   And in will in no way reduce spam.

This document is an Internet draft and is on its way to the RFC Editor. 
Is this something that is worthwhile to be published as an RFC? 
Comments, anyone?

Yakov

---

From: "Curtis M. Kularski" <[email-masked]>
Date: Thu, 2 Oct 2003 16:14:37 -0400 (Eastern Daylight Time)

You mention that the draft lacks "beef", well before it was a lot better
in my opinion, but the RFC Editor didn't like it, so i revised it to make
it more compact and more direct. Now that I think about it, the host-based
portion is only logical when there are few enough users to actually be
able to configure each sub-domain by hand. On a larger scale, such as for
ISPs the hypened or dotted notations would make more sense.

The point of the draft is more of to make the proccess of sorting and
deleting SPAM easier than to block specific senders. I personally have my
sub-domain manually specified and have my server allowing the nobody alias
to function (but the server is making a log of what incoming addresses are
used in case that needs to change), and then any address that gets spammed
is specified manually as an alias and pointed to a seperate SPAM account
which i skim over about once a week. The procedure that the draft
specifies is by no means a 100% cure for SPAM, but in my implementations
for personal use and for about 50 other people it has been very effective.

Curtis

>>    This document gives instructions for implementing a mail system
>> that will reduce the amount of SPAM received by the end users. The
> SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89)
> 32356-0 Research & Development |       D-80807 Muenchen    | Fax: +49
> (89) 32356-299 "The security, stability and reliability of a computer
> system is reciprocally

---

From: Markus Stumpf <[email-masked]>
Date: Thu, 2 Oct 2003 22:12:30 +0200

> Is this something that is worthwhile to be published as an RFC? 

IMHO it is not.
It describes in no way a "mail system that will reduce the amount of SPAM".
And there are tons of open questions ...

When I read this I had the feeling this document is like:

  Title: "This document describes a new way to explore space"
  Content: Let's fly to Mars and using a rocket would probably be a good idea.

	\Maex

---

From: Markus Stumpf <[email-masked]>
Date: Thu, 2 Oct 2003 22:24:22 +0200

> for personal use and for about 50 other people it has been very effective.

Yes, it works for me, too.
I had a webpage for a limited time frame and used a special email
address. 4 weeks after the time frame was over I blocked the address
in the mailserver and spam went away.

But in which way is your system in principle different from a TMDA
(Tagged Message Delivery Agent) system?
    http://tmda.net/
and especially
    http://tmda.net/config-client.html
Isn't the system described there not even more flexible and successful
than yours?

	\Maex

---

From: "Curtis M. Kularski" <[email-masked]>
Date: Thu, 2 Oct 2003 16:33:59 -0400 (Eastern Daylight Time)

I think it would be helpful if I posted a link to where my old drafts can
be accessed: http://curtis.kularski.us/internet-drafts.

draft-kularski-spam-spamreduce-03 was the document I previously sent to
the RFC editor for review, and I was told the following regarding the
draft:
" There MIGHT be room for a clever new
idea that was succinctly and clearly described.  Unfortunately, your
document needs to be rewritten to be clear about the essential idea you
are suggesting."

That is what I tried to do in 05, as well as address some possible DNS
issues in 03 that were also mentioned by the RFC Editor (not posted here
because the Editor misunderstood some aspects of the draft).  I think the
main problem with my drafts has been that I am focusing on what has been
successful in a relatively small implementation and not able to see what
would work best for everyone else.

This draft is not meant to set a standard of any type, this draft's
purpose is to provide documentation of one possible way to deal with SPAM.
This method isn't for everyone, but I feel that it could be useful to a
lot of people who are in a situation where there is more than one user on
the domain, but yet there isn't a huge amount of users on the domain
either.

My personal implementation of the procedure is more like what is mentioned
in draft 03, and I think that draft 05 is starting to stray a little from
the original intent. The reason for the sub-domain and not the user dotted
or user hyphened format is because it is more of a clean address, not
complicated and lengthy.

I really appreachiate input that is given about the draft and I hope that
I can find ways to address all of the concerns.

Curtis

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 3 Oct 2003 00:10:49 -0400

>    will allow for the source of SPAM to be easily identified.

I'll confess, I haven't read it.  But from the description I have 
several comments.

1. I've been using per-domain addresses for several years (e.g. 
[email-masked]).  I've gotten very confused at 
times in registration systems when a company changes it's name, but I 
have never received spam to any of them.  Guess I don't give my 
address to unscrupulous companies.
That said, I full expect to get spam eventually.  It happened to one 
of my older addresses.  One of the companies I gave it to went out of 
business and sold their address list.  Which leads me to #2.

2. So I know who sold my address.  What does that gain me?  It 
certainly doesn't stop the spam.  It doesn't even tell you who has 
the address now.

3. Spreading lots of different email addresses around is a bad idea. 
The fact that you know you can reject them really doesn't help.  As 
we speak, my mail server is eating up 8-16KBs of bandwidth right now 
doing nothing but rejecting email sent to non-existent addresses. 
Yesterday some idiot on Level3's network tried to connect to our mail 
server 500,000 times.  You do *not* want that happening to your mail 
server.  Increasing the number of throwaway addresses simply 
increases the bandwidth costs of spam.

4. I gather from other comments that the technique uses wildcard 
addresses.  I tried that just the other day.  I figured I'd set up a 
wildcard address for somewhere.com that pointed to Versign's 
"service".  I thought maybe they'd enjoy all the traffic from people 
attempting to ftp to ftp.somewhere.com, or spam smtp.somewhere.com, 
and so on.  Three pieces of software in my network broke in the next 
two days and I gave up and got rid of it.

-- 
Kee Hinckley
http://www.messagefire.com/         Next Generation Spam Defense
http://commons.somewhere.com/buzz/  Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

---

From: "Jon Kyme" <[email-masked]>
Date: Fri, 03 Oct 2003 13:18:04 +0100

> http://www.ietf.org/internet-drafts/draft-kularski-spam-spamreduce-05.txt

Have comments been sought from the many providers
of disposable address systems?

--

---

From: Dave Crocker <[email-masked]>
Date: Fri, 3 Oct 2003 12:41:00 -0700

Yakov,

YS> The ASRG has been asked to comment on the following draft:
YS> http://www.ietf.org/internet-drafts/draft-kularski-spam-spamreduce-05.txt

The author should provide an evaluation of the proposal, such as by using the
questions/criteria listed in the -techconsider- document.

The results are certain to be interesting.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: "Curtis M. Kularski" <[email-masked]>
Date: Fri, 3 Oct 2003 16:18:13 -0400 (Eastern Daylight Time)

I find item #1 humorous, "unscrupulous companies". Ever shopped with
Amazon.com? They sell addresses, but yet have a high amount of consumer
trust.

In response to item 3, the idea of the disposable address is for the
server to dispose of the mail and not respond. The server would forward
the mail to a dead-end account.

Curtis

> That said, I full expect to get spam eventually.  It happened to one  of
> my older addresses.  One of the companies I gave it to went out of
> certainly doesn't stop the spam.  It doesn't even tell you who has  the
> address now.
>
> The fact that you know you can reject them really doesn't help.  As  we
> speak, my mail server is eating up 8-16KBs of bandwidth right now  doing
> nothing but rejecting email sent to non-existent addresses.  Yesterday
> some idiot on Level3's network tried to connect to our mail  server
> 500,000 times.  You do *not* want that happening to your mail  server.
> Increasing the number of throwaway addresses simply
> attempting to ftp to ftp.somewhere.com, or spam smtp.somewhere.com,  and
> so on.  Three pieces of software in my network broke in the next  two
> days and I gave up and got rid of it.
>
> --
> Kee Hinckley
> I'm not sure which upsets me more: that people are so unwilling to
> accept responsibility for their own actions, or that they are so eager
> to regulate everyone else's.
>

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 03 Oct 2003 17:32:32 -0400

> of disposable address systems?

The ones in the group aren't speaking up and others have not been 
contacted. Is the author planning on doing that?

Yakov

---

From: "Curtis M. Kularski" <[email-masked]>
Date: Fri, 3 Oct 2003 20:22:35 -0400 (Eastern Daylight Time)

Yes, I will handle that after I complete my response for the
"techconsider" questions. I would like their feedback on the draft,
especially since it builds on the base idea that they use.

Curtis

---

From: "Curtis M. Kularski" <[email-masked]>
Date: Fri, 3 Oct 2003 20:39:42 -0400 (Eastern Daylight Time)

Mr. Crocker,
  Thank you for suggesting that I do that (although, in the future, please
direct requests for me to me). From answering the questions I have found
a few things I need to explain better in the draft, and I thought of
some ideas for corporate users that may be more helpful than what I
currently have specified. The response document is attached.

Curtis

> YS>
> The author should provide an evaluation of the proposal, such as by
> using the questions/criteria listed in the -techconsider- document.
>

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 3 Oct 2003 21:16:13 -0400

>Amazon.com? They sell addresses, but yet have a high amount of consumer

As I mentioned, I use tagged email addresses.  I've shopped with 
Amazon.com since they opened the store.  I've never had them sell my 
address.  They *did* expose it to the public once, when I commented 
on an auction vendor, not realizing they would use my amazon.com 
address, but that was easy enough to fix once I realized it.

What evidence do you have that they sell addresses?

>the mail to a dead-end account.

Those two statements contradict each other.  Either you reject the 
mail, or you forward it.  If you forward it, then you get a *huge* 
bandwidth hit.  I assumed that you would reject it, and my example 

>  > increases the bandwidth costs of spam.

None of those addresses are being accepted.  That bandwidth and 
traffic comes from bouncing spam and viruses sent to 40,000 
non-existent addresses.  We bounce one every two seconds in normal 
times, 10-15 a second during peak virus season.  To put that in terms 
of throw-away addresses, I'd guess that an average user might have 20 
throwaways in a year, so call that the traffic for 2000 users (the 
first year--of course it doubles every year after that).

Throwaway addresses are based on the assumption that sending mail to 
a non-existent address is "free".  It isn't.
-- 
Kee Hinckley
http://www.messagefire.com/         Next Generation Spam Defense
http://commons.somewhere.com/buzz/  Writings on Technology and Society

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 07 Oct 2003 21:42:09 -0400

Curtis M. Kularski wrote:

> Mr. Crocker, Thank you for suggesting that I do that (although, in
> the future, please direct requests for me to me). From answering the
> questions I have found a few things I need to explain better in the
> draft, and I thought of some ideas for corporate users that may be
> more helpful than what I currently have specified. The response
> document is attached.
> 
> Curtis
> 
> 
>> Yakov,
>> 
>> YS> The ASRG has been asked to comment on the following draft: YS> 
>> d/ -- Dave Crocker <dcrocker-at-brandenburg-dot-com> Brandenburg
>> InternetWorking <www.brandenburg.com> Sunnyvale, CA  USA
>> <tel:+1.408.246.8253>
>> 
>> 
>> _______________________________________________ Asrg mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/asrg
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
>> Response to Dave Crocker's request to respond to the Tech-Consider
 >questions.
> 
> 1. Adoption Effort - The proposed mechanism can be added to existing
> implementations of SMTP servers without any major adjustments. The
> only additional mechanism required is the ability for a user to add
> and remove accounts for his/her account.
>

Adoption applies to other things besides SMTP servers. What about ISPs 
and organizations that want to adopt such scheme? Is it feasiable to 
authomated it? Are support costs factored in?

> 2. Threshold of Benefit - users who adopt the mechanism will have
> immediate benefits. Success for a user is determined only by the
> user's adoption of the procedure.  No outside inflence is required.
> 

This is a good thing - its looks alike an edge mechanism rather than a 
core one.

> 3. Impact - Senders will only notice a different email address,
> nothing will be technically different for them. Recipients will see
> nothing different in the receive proccess, but when distributing
> addresses they will have to be concious of what address they assign.
> The styles of operation aren't significantly changed.
> 

What about impact on the receivers from the management viewpoint? Would 
managing this multiple addresses be an issue?

> 4. Impact (external) - No effects to external parties will occur.
> Legitimate email users will not be blocked by this procedure.
> Spammers can pass through for the first time, but as soon as the user
> identifies the "TO" address as an address that is being attacked by
> SPAM the address can be flagged and all mail to it can be disposed
> of. There is no change of nature of email for people who don't adopt.
> 

What about dictionary attacks? Can a spammer use that to find out all of 
the addresses at a domain (depending on how addresses are generated that 
might be an awfully long process)?

> 
> 5. Ongoing effort - maintainance is minimal. the users will add or
> discontinue addresses as needed. The procedure does not effect affect
> regular email.
> 

What about the management effort from the users? Once again, are there 
automated tools?

> 6. Balance of Burden -  The burden is mostly on the user, but the
> burden is minimal, the only work required is maintaining the list,
> and that function could easily be intergrated into an email client to
> allow for easy list manipulation.
> 

How easy? Can you provide more details on what burden would the user 
have? If a user uses thousands of sites, with a unique address for each 
one, that might be a larger burder than someone's grandmother that uses 
two. On the other hand, most grandmothers will not be savvy enough to 
use this.

> 7. Use by Full Internet - If everyone adopts it, then everything
> should still function normally (except a lot less SPAM). The fabric
> of Internet mail should see no ill effects, even if this is used on a
> large scale.

Ok.

> 
> 8. Growth - Increasing by 1000 times should not be a problem, as long
> as the mail servers are upgraded as they would be if this procedure
> wasn't in place. The fabric of Internet mail is still safe.
> 

Why would mail servers need to be upgraded? Is there extra functionality 
required to keep track of the addresses?

> 9. Efficiency - The proccess uses existing techniques (although used
> for different purposes) efficiently, and this procedure can use them
> efficiently also. The proccess will be able to operate at about the
> same speed as current, but some mild delays (not more than a few
> seconds) could be incurred while mail is being sorted. Proccessing is
> a little higher while mail is sorted and the alias is followed, but
> existing mails systems do it all the time without any consequences,
> storage requirements will be less because the mail is being sorted
> and most SPAM is hitting a dead-end box that is deleting mail
> instantly.
> 

Ok.

> 10. Cost - No major expense will be incurred.
> 

What about costs of management and support on organizational level?

> 11. Reliability - Non-SPAM mail should all arrive in its proper
> location, the user has control over what gets in and what doesn't.
> Non-SPAM is more likely to arrive at its destination and not be lost,
> due to both the end user control and the absense of distracting SPAM.
> 
> 

Ok.

> 12. Internet Impact - Only the parts that adopt it.
> 

Ok.

> 13. SPAM Impact - SPAM sent to addresses determined by methods other
> than guessing, and dictionary attacks should be very well suppressed.
> Once an attacked address is identified it can be eliminated, there is
> still the issue of the intial mail, which prevents this procedure
> from being 100% SPAM-free.
> 

Dictionary attacks are not to be underestimated and it would be 
interested to see whether the use of creative addressing actually 
increases them. Something to pass long to the analysis folks.

> 14. Circumvention - the only way to circumvent the procedure is to
> find another address after the first time mail is sent (because of
> the user's ability to kill addresses). If a catch-all is used by the
> user it may be circumvented with a simple random addressing (this is
> why this was removed from the draft, and discouraged in future
> drafts). No effect to non-SPAM mail will occur unless non-SPAM
> mailers sell their address lists to SPAMers.
> 

Ok. What about dictionary attacks, isn't thata form of circumvention?

> 15. Personal Post/Reply - using the personal email option, which uses
> a whitelist, will require the sender to respond to a whitelist
> addition request. If the personal option is ommited, then the sender
> will initiate an email with the recipient as usual (using the address
> provided), but most likely using a unique FROM address.  Once a
> "trust" is establised the two can use a simple-non unique address if
> one is availible.
> 

Is this a form of C/R?

> 16. Mailing Lists - mailing lists will be assigned their own address
> like anything else used by the user. All replies, etc should still
> work. As a personal reccomendation, each list should be given its own
> full address on the server, and not just an alias for easy
> management, but that should be left to the user's discretion.
> 

Ok.

> 17. InterEnterprise - an address shall be issued for each user with
> the name of the team in it, such as [email-masked] (or
> [email-masked]). As team affiliation changes the address can
> be modified. Intrateam communication should not be affected. For
> internal enterprise communication an address similar to the personal
> (trusted source) address should be used.

What about support and management costs for organizations?

---

From: "Curtis M. Kularski" <[email-masked]>
Date: Wed, 8 Oct 2003 23:48:43 -0400 (Eastern Daylight Time)

> authomated it? Are support costs factored in?

ISPs would need to add an authenticated form of some type for their users
to use for updating their lists. The entire proccess can be easily
automated as far as adding support for the mechanism. Assuming that an ISP
has a database of users a simple WHILE loop utility could transform the
configurations to be what is required for the particular server. Most
likely it wouldn't need to be an automated conversion though, it would be
best to let it be a per-user option at first and let the users volentarily
switch over.

As far as when new users are added to the system, their accounts should be
created however they normally are, except the "real" address is hidden to
the outside world and only the alias addresses that are specified will
exist. Initially the ISP will probably want to add an alias for them to
use to communicate with the client.

> This is a good thing - its looks alike an edge mechanism rather than a

Definately, the last thing I want to do is violate how SMTP operates, and
I think that a system to reduce the amount of SPAM should be something
that doesn't require everyone to change for it to work. The idea behind
this is that even if you are the only person on the internet to ever use
this, you will have significant SPAM reduction.

> managing this multiple addresses be an issue?

Most likely it will be something that the user will have to adapt to, but
not a major issue. I would like to develop a client-side utility that
possibly snaps into the email client to help with the reciever management,
but for now i am taking this one step at a time. One thing that may be
worth considering here would be some type of queue system (10 day or so
queue time), so if the user forgets to add an address, but eventually does
add it, then mail can be proccesed, decreasing the chances that mail is
lost due to overprotecting the box.

>> SPAM the address can be flagged and all mail to it can be disposed of.
>> There is no change of nature of email for people who don't adopt.
>>
>
>  the addresses at a domain (depending on how addresses are generated
> that  might be an awfully long process)?
>

Dictionary attacks are still an issue, but not nearly as big of a problem.
With two unique components to the address it becomes increasingly
difficult to find valid addresses. First they have to find a valid user,
then they have to find an address that the user has authorized. The more
creative a user is with their naming for popular sites/words the better
protection the user will have. This is a case where the "disposable"
factor becomes a very nice feature, if a term is found, then the user just
has to kill it. A dictionary attack would most likely not be cost
effective for SPAMers who try to attack this mechanism, more effort on a
single user's addresses would be required than what would be required for
an entire domain that doesn't have this mechanism implemented.

> What about the management effort from the users? Once again, are there

This is one of those things that I still need to work out a little better,
but as I stated earlier, i would like to see about some type of client
snap-in.

>> burden is minimal, the only work required is maintaining the list, and
>> that function could easily be intergrated into an email client to

If a user uses thousands of sites, then there is reason to use the
wildcard alias (with selective alias deactivation availible) for the
user's email needs. Granny can adapt just as other users will, it is just
a matter of making the utility for adding and removing addresses visible
enough. Initially granny probably had problems understanding the concept
of how email works, but she used it a few times and learned how to use it
effectively.

>> should still function normally (except a lot less SPAM). The fabric of
>> Internet mail should see no ill effects, even if this is used on a
>> large scale.
>
> Ok.
>
>>

More users = More traffic. The upgrades mentioned are the maintaince
upgrades that administrators would be performing due to user growth
anyway. There is no extra functionality required to keep track of the
addresses, basicly just store the information however you store user
information currently.

>> storage requirements will be less because the mail is being sorted and
>> most SPAM is hitting a dead-end box that is deleting mail
>> instantly.
>>
>
> Ok.
>

Managing the users will require no more effort, resources or expense than
it currently does. Adding and dropping users will occur like it does now,
only the results will be a little different. Think of it sort of like DNS
in this aspect, current email users operate like address records, 1 name
to 1 box managed directly by the administrator/automated system. This
mechanism is more like a NameServer record, you are creating the user's
account, but delegating control of what happens in the namespace to that
user's control. In that area there would likely be a small increase in
cost for the component that adds aliases for the user on their management
side. Support incidents could see a very small increase for ISPs (assuming
volentary adoption of the mechanism per user), on the organizational side
the number of support incidents could increase significantly for a very
short period of time while users adapt, but after it is implemented there
should be no more incidents than are incurred with current email
practices.

>> still the issue of the intial mail, which prevents this procedure from
>> being 100% SPAM-free.
>>
>

Over the weekend I had a friend to perform a test dictionary attack on my
mail server, directed at my subdomain (i have opted to use subdomain for
my mail because of the size of the implementation). Out of about 75
addresses I have specified only 1 was hit after a 6 hour attack.

I would like to see an analysis of the dictionary attack issue, I have no
valid way of testing this other than sample attacks currently.

I dont think that the creative addressing method will increase the amount
of dictionary attacks, espcially if SPAMers determine that it is a futile
effort.

>> find another address after the first time mail is sent (because of the
>> user's ability to kill addresses). If a catch-all is used by the user
>> it may be circumvented with a simple random addressing (this is why
>> this was removed from the draft, and discouraged in future

Yes, and it still is a very real possibility. Other than issueing
addresses as an MD5 string I haven't seen any complete way to avoid
dictionary attacks.

>> "trust" is establised the two can use a simple-non unique address if

C/R? I am unsure of what you mean.

> What about support and management costs for organizations?

Initial support would be more costly, the same as with anything new that
is implemented network wide that interacts with users.

Things I have determined so far: I need to work on the dictionary attack
issue and find more detailed information about support and management
costs.

---

From: "Tom Thomson" <[email-masked]>
Date: Thu, 9 Oct 2003 18:30:01 +0100

I don't see what this would give us that we wouldn't get from a pure
whitelist.  Since the user must assign a unique email address for
communication from each non-trusted source, no source that the user isn't
aware of can ever send mail to him; So he might just as well maintain a list
of those sources allowed to send mail to him.

Providing a structure for transient/disposable email addresses could be
useful as working out who the target is can be done by parsing the address
instead of by a lookup; but a lookup is still needed to allow (the email
address corresponding to) a source to be blacklisted so it probably doesn't
work very well after all.

I don't think this is useful or will make any contribution to reducing spam.

Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Yakov
Shafranovich
Sent: 02 October 2003 19:03
To: ASRG list
Subject: [Asrg] 6. Proposals - Creative Addressing

Abstract:

"

---

From: "Tom Thomson" <[email-masked]>
Date: Thu, 9 Oct 2003 18:53:14 +0100

Kee Hinckley wrote:-
> a non-existent address is "free".  It isn't.

I don't think so - I sometimes use throwaway addresses, and the
organisations that provide them are interested in collecting information
about spam; these throw-away addresses are a cheap way of collecting spam
samples - not a free way of doing that.

Of course this doesn't apply to the proposal we were asked to comment on,
which does seem to be based on the invalid assumption you refer to.

Tom