Re: [Asrg] Do we need to do anything?

[Jim Youll <jim@media.mit.edu>]

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@jmason.org,
> I have to maintain a mapping between "posting to the foo list" means
> "use jm-list@jmason.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@domain.com>... No such user here
	Mar  2 16:10:47 new sendmail[15206]: h22LAlW15206: 
<tony@domain.com>... No such user here
	Mar  2 16:10:47 new sendmail[15206]: h22LAlW15206: 
<daniel@domain.com>... No such user here
	Mar  2 16:10:47 new sendmail[15206]: h22LAlW15206: 
<lee@domain.com>... No such user here
	Mar  2 16:10:47 new sendmail[15206]: h22LAlW15206: 
<jack@domain.com>... No such user here
	Mar  2 16:10:47 new sendmail[15206]: h22LAlW15206: 
<craig@domain.com>... No such user here
	Mar  2 16:10:47 new sendmail[15206]: h22LAlW15206: 
<sam@domain.com>... No such user here
	Mar  2 16:10:47 new sendmail[15206]: h22LAlW15206: 
<pete@domain.com>... No such user here
	Mar  2 16:10:47 new sendmail[15206]: h22LAlW15206: 
<andy@domain.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@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg