On Jan 11 2005, Seth Breidbart wrote:
Laird Breyer <laird(_at_)lbreyer(_dot_)com> wrote:
A way to break ISACS by spamming mailing lists.
It isn't quite that simple, though; if a user of ISACS turns off the
subaddress used by a mailing list, he should unsubscribe and
resubscribe a new subaddress. This puts the work where it belongs, on
the user of ISACS.
I agree. However, the simple act of turning off the address still
automatically send a challenge back to the list address even if the
user unsubscribes and resubscribes afterwards. So ISACS now has to have a
subsystem for dealing specially with mailing lists, or else the user
should bypass ISACS, unsubscribe/resubscribe *first*, then
turn off the subaddress, all of this manually.
In Peter's variation, simply turning off the subaddress could be
undetected, resulting in loss of service to the subscriber contrary
his expectation, or if detected it's still a cost to decode the
challenge. I'd expect list operators to not request the provided
challenge URL as a matter of policy. So the user would, by turning
off the address, still obtain an unexpected side effect: losing access
to the list. This is unexpected because, if ISACS is widely deployed,
then the act of turning of a subaddress for one to one email
simply induces the sender to retry.
Of course, it doesn't matter: the spammer will just spam the list
again. So the users of ISACS won't (effectively) unsubscribe from the
list just because it gets spammed, but will decide how to deal with it
the same way everybody does now.
If ISACS users must pre- or post-filter all their mail independently
from the ISACS system, a legitimate question becomes what ISACS brings
to the table in that case.
--
Laird Breyer.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg