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? Obviously it would result in
a huge number of failures, but the fact that spammers now use
dictionary attacks (and worse) suggests that they would be just as
willing to try that approach.
I probably being cavalier about the changes need, but they might be a
reasonable price to pay to forever exclude mailing lists from bulk
detectors and whitelist management hassles.
It doesn't sound that unreasonable to me (then again, I think HTML e-
mail should be eliminated so maybe I'm not the best person to define
"reasonable"), but I think a crypto approach (preferably one that
doesn't involve making annual rental payments to some "authority" for
the use of a very large number; i.e., the list is it's own authority)
might be more technically solid.
Ideally, what I would like to see is some approach that requires
large CPU overhead for sending a large number of messages, because
this should at least throttle the bulk mailers. There are a couple
of variations to this approach that I think might be workable, such
as a mail protocol where the sender first sends a "i'm about to send
a message" message, and the receiver generates a key pair, sending
the arbitrary "public" key to the sender, who then uses it to encrypt
the message, which is then sent to the receiver who can decode it
with the private key. One obvious problem with that approach is that
the receiver does too much work (key generation), but that duty can't
be given to the sender for obvious reasons (key reuse, etc., as well
as the fact that if you're going to go to that much trouble you might
as well get "secure" transmission out of it as well). Thus, the only
way it would be workable is to use an algorithm where key generation
is fast, decryption is fast, but encoding is very CPU intensive, a
combination that doesn't seem very likely.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg