At 19:42 +0000 3/6/03, Justin Mason wrote:
The issue I've had with tagged addresses (which I use BTW in some cases)
is a usability one -- if I subscribe to a list with
jm-list(_at_)jmason(_dot_)org,
I have to maintain a mapping between "posting to the foo list" means
"use jm-list(_at_)jmason(_dot_)org for the From address" (since most sensible
lists
impose From-addr filtering to avoid spam).
Giving a different e-mail addr to each correspondent breaks down in this
case, since I may be replying to Jim Youll, ccing Matt Sergeant, and the
ARSG list. Which from addr do I use in this case? If only the Asrg
list had so far had a tagged address mapping, that would be doable. But
if all 3 had, it's more difficult; I'd have to tell my software that
Asrg takes priority, use its address, etc.
Right. So the obvious "correct" answer in this case, where one address (asrg)
contains the others (jim,matt) the most all-inclusive address is the one
to use.
Your software doesn't know that. However, if the list were putting a
Reply-To on the message (I think it should) then your software would. Absent
that, since joining a confirmed mailing list is a "big" event compared to most
e-mail activity, an enlightened e-mail client/server that could
generate and maintain
these many addresses would also presumably have the smarts to figure
out what's up.
At 13:35 -0600 3/6/03, wayne wrote:
However, I don't think this kind of thing is a good solution.
Enough spammers continue to spam long after an account has been
deactivated that systems like sneakemail will experiences an ever
increasing ratio of spam to valid email. People will also still have
to deal with switching email addresses.
Sure, that's a concern. However with spammers now trying to cruise the
entire name-space of domains, it doesn't even matter so much....
from the logs this week, of a domain (name elided) that I host...
Mar 2 16:10:47 new sendmail[15206]: h22LAlW15206:
<fred(_at_)domain(_dot_)com>... No such user here
Mar 2 16:10:47 new sendmail[15206]: h22LAlW15206:
<tony(_at_)domain(_dot_)com>... No such user here
Mar 2 16:10:47 new sendmail[15206]: h22LAlW15206:
<daniel(_at_)domain(_dot_)com>... No such user here
Mar 2 16:10:47 new sendmail[15206]: h22LAlW15206:
<lee(_at_)domain(_dot_)com>... No such user here
Mar 2 16:10:47 new sendmail[15206]: h22LAlW15206:
<jack(_at_)domain(_dot_)com>... No such user here
Mar 2 16:10:47 new sendmail[15206]: h22LAlW15206:
<craig(_at_)domain(_dot_)com>... No such user here
Mar 2 16:10:47 new sendmail[15206]: h22LAlW15206:
<sam(_at_)domain(_dot_)com>... No such user here
Mar 2 16:10:47 new sendmail[15206]: h22LAlW15206:
<pete(_at_)domain(_dot_)com>... No such user here
Mar 2 16:10:47 new sendmail[15206]: h22LAlW15206:
<andy(_at_)domain(_dot_)com>... No such user here
This is not a perfect nor all-encompassing solution. I see it as a
potentially useful tool for these reasons:
1. Self-help. It does not require a wholesale change to anything
outside the user's local environment. It can be handled in a client
with a little help on the server side.
2. Load-reduction... when a user learns that an address has been
compromised and cancels the old address, the incoming server can kick
messages at <rcpt to> rather than handling all of it.
The very thought of dealing with unsubs and resubs and updates... not
pleasant at all, but it's the user's choice, really, and it doesn't
demand cooperation of anything beyond the local circle of the user
and his mail server.
IBM did some work on this several years ago, and covered the entire
subject pretty thoroughly.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg