At 07:12 PM 7/7/2003 -0400, Barry Shein wrote:
Well, there's one characterization from measurements mentioned which
spammers can't adapt to and that's their location (in)stability in IP
space.
This relates to the idea that the only reason spammers can operate
effectively is because they exploit thousands of hijacked computers
which gives them location mobility (not geographic but in ip space.)
If this can be shown to be true via measurement it leads to the
conclusion that perhaps the problem with spam is not what leads to
this idea of a "consent" framework as originally proposed in this
charter, but, instead, shows spam is almost entirely a security
problem.
Spammers can't adapt their way out of this observation because that
would mean they'd have to become location immobile which means we
could just block them and that'd be the end of spam.
If it were only that simple. The good news is that IP stability is a
powerful tool for establishing senders and their behaviors - not perfect,
but very, very good. The bad news is that the definition of spam is often
very different from one RECEIVER to another... so the same IP source may be
producing spam, or ham depending upon your point of view. Therefore,
RECEIVER A and RECEIVER B would likely have identical policy definitions
for the SENDER's identity, but different policy definitions for the
disposition of the sender.
<RECEIVER>
<ID VALUE=RECEIVER-A(_at_)EXAMPLE(_dot_)COM />
<SENDER>
<ID VALUE=01234 />
<IP-SOURCE VALUE=111.222.123.231 />
</SENDER>
...
<GRANT-CONSENT>
<SENDER-ID VALUE=01234 />
</GRANT-CONSENT>
...
</RECEIVER-A>
<RECEIVER>
<ID VALUE=RECEIVER-B(_at_)EXAMPLE(_dot_)COM />
<SENDER>
<ID VALUE=01234 / >
<IP-SOURCE VALUE=111.222.123.231 />
</SENDER>
...
<DENY-CONSENT>
<SENDER>
<ID VALUE=01234 />
</SENDER>
</DENY-CONSENT>
...
</RECEIVER>
A given RECEIVER may even CONSENT to receive messages from the sender under
some other conditions... which further complicates the definition process,
but no without bounds.
_M
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg