Responses to Yakov Shafranovich's concerns:
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?
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.
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.
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.
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?
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.
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)?
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.
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?
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.
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.
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.
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?
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.
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?
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.
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.
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.
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?
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.
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?
C/R? I am unsure of what you mean.
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 user(_dot_)team1(_at_)example(_dot_)net
(or
team1(_at_)user(_dot_)example(_dot_)net). 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?
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.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg