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>
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>
_______________________________________________ Asrg mailing list
Asrg(_at_)ietf(_dot_)org 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 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?
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg