On Sat, Mar 08, 2003 at 10:49:39PM -0600, tjacobs(_at_)redsword(_dot_)com
allegedly wrote:
But, as Vernon says, doing so doesn't need fancy crypto solutions.
This could be as simple as a new header field that tells the MUA to
generate a unique token - let's call it a confirmation token - as part
of the confirmation reply. Heck, even the Message-ID might do.
If the mailing list s/w records the confirmation token and then uses
it in all subsequent outbound email to the subscriber, than the MUA
can reliably override any bulk detectors/indicators that might be set
by the ISP/MUA/whatever.
Short of the protections offered by some "fancy crypto solutions",
what is to keep a spammer from using the public algorithm used in
generating tokens to generate his own?
But the public algorithm is merely a variant of rand()
The MUA can generate any sort of token it wants. All it has to do is
send the token back to the mailing list as part of the confirmation
email *and* keep a copy in some local database.
To: list-confirm(_at_)ietf(_dot_)org
From: joe(_at_)example(_dot_)com
Confirmation-Token: 20700621ba1d4f92de29ffce0dc98b0d
Henceforth the list/e-commerce site includes that token in all email
addressed to joe(_at_)example(_dot_)com
The MUA in turn, is told that the mail is bulky by the presence of,
eg, a "Precedence: bulk" header, thoughtfully placed their by your
bulk-aware inbound MTA. That header triggers the MUA to check that
the "Confirmation-Token:" matches an entry in its local database. If
there is no match, punt.
To accumulate a spammer-load of victims a spammer has to:
o guess the address-token combinations on a large scale
o break into to MUAs database of a lot of recipients
o intercept traffic on a large scale
o break into a lot of mailing list databases
o acquire them from an unscrupulous mailing list/e-marketer
All of these are hard, excepting perhaps the last one, and even then
they are a one-time target for the spammer as one can readily imagine
an MUA interface that lets the user discard a compromised token.
As I said previously, this is not intended as a proposal, rather it's
meant to demonstrate that relatively modest changes are possible that
reliably disambiguate lists from spam.
But, whether our fragmented and fractious industry can even achieve
modest changes is possibly the first question this RG needs to answer.
Regards.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg