On Jan 09 2005, Michael Kaplan wrote:
Again you are assuming that everybody will be using the same system.
How can the mailing list software know that they are a single entity?
After all <peter(_dot_)holzer(_at_)wsr(_dot_)(_dot_)(_dot_)> and
<peter(_dot_)janecek(_at_)wsr(_dot_)(_dot_)(_dot_)> aren't two
mail addresses of the same person, either. One is mine, the other
belongs to a colleague two doors down the hall.
When my system is activated all existing addresses are grandfathered in.
Now peter(_dot_)holzer(_at_)wsr as an individual activates my system and he
can use
any sub-address he wants except the system will not allow him to use
"janecek." Now no one else can establish an account with a
peter(_dot_)????(_at_)wsr
address.
But when your system is activated, there may already be multiple users
with addresses of the form peter(_dot_)????(_at_)wsr to begin with. Who gets to
use the future peter(_dot_)XXX(_at_)wsr sub-address space?
The holder of the account peter(_dot_)janecek(_at_)wsr was slow in activating
the system so he can keep his current peter(_dot_)janecek(_at_)wsr address but
he cannot activate my system and use "peter" as the invariant part
of his email address. If he wants to use my system then he can
select the address peterj(_dot_)lucky(_at_)wsr(_dot_)
How will his existing correspondents know that mail from
peterj(_dot_)lucky(_at_)wsr comes from peter(_dot_)janecek(_at_)wsr, and not
some spammer
who picked a bogus address?
Now back to original question: How will a mailing list handle this?
Well, obviously both peter(_dot_)holzer(_at_)wsr and
peter(_dot_)janecek(_at_)wsr must
register for the same mailing list. Both will receive the list
mail in an unimpeded manner. Both can post to the list, and just like
the current system the human members of the list will be likely know
that these are two different people.
If the mailing list amalgamates the sub-address space, then the following
happens:
1) peter(_dot_)holzer(_at_)wsr registers to the mailing list
2) anybody claiming to be peter(_dot_)XXX(_at_)wsr can post to the list
3) A spammer reads the public list archive, looking for addresses such as
peter(_dot_)holzer(_at_)wsr
4) This spammer sends mail as peter(_dot_)aaaa(_at_)wsr to the list.
Now the list operator deactivates peter(_dot_)???(_at_)wsr, and next week when
peter wants to send to the list, he can't.
Perhaps the list operator has a sophisticated system, and he disables
the address peter(_dot_)aaaa(_at_)wsr only. Then the following occurs
5) This spammer sends mail as peter(_dot_)aaab(_at_)wsr tomorrow.
It is disabled a day later.
6) This spammer sends mail as peter(_dot_)aaac(_at_)wsr a day later.
It is disabled a day later.
7) This spammer sends mail as peter(_dot_)aaad(_at_)wsr a day later.
It is disabled a day later.
8) This spammer sends mail as peter(_dot_)aaae(_at_)wsr a day later.
It is disabled a day later.
9) After a week of spamming, the other list members complain and/or
change their subaddresses, resulting in many new CAPTCHAs sent to the
list operator, resulting in hours wasted.
10) The new subaddresses used by everyone are still of the form
peter(_dot_)???(_at_)wsr etc., so the spammer doesn't need to change his address
generator and can continue to spam as follows:
11) This spammer sends mail as peter(_dot_)aaaf(_at_)wsr tomorrow.
It is disabled a day later.
12) This spammer sends mail as peter(_dot_)aaag(_at_)wsr tomorrow.
It is disabled a day later.
13) This spammer sends mail as peter(_dot_)aaah(_at_)wsr tomorrow.
It is disabled a day later.
14) A new wave of CAPTCHAs is sent.
Etc.
--
Laird Breyer.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg