In any event, we have an emerging, large-scale problem. We need to
find some workable solutions. This will require adjustments for us all.
Adjustments doesn't mean massive changes to a draconian set of mechanisms,
but it does mean that the old world we've lived in is changing.
True enough, but the emerging, large-scale problem I believe you're referring
to (spamming) is not addressed in any significant way by requiring verification
of subscription requests.
The only problems that subscription verification addresses are that of
attacking someone by subscribing them to lots of lists and that of increasing
numbers of bogus subscription requests.
I do not believe the first problem is significant at this time. It may be in
the future, and if so verification of requests will be widely employed to solve
it, I hope. But I believe the list managers of the world are gong to require
more than a couple of isolated incidents to justify the use of such mechanisms.
The second problem is, in my opinion, becoming less of an issue as the Internet
becomes better integrated and more homogeneous. NOTARY also provides effective
mechanisms for dealing with it in an automatic way that doesn't inconvenience
anyone.
That does not, of course, mean the this specific mechanism is
essential, but I do believe it improves the integrity of the data base
rather substantially. The side effect, then, is to reduce bounces.
Bounces that only the list manager sees, bounces that comprise only a small
part of the ongoing work a list manager does, bounces that along with all the
others are dealt with more effectively by implementation of NOTARY.
I do think the problem of handling bounces is a major issue for list managers.
But subsciption verification only deals with a small fraction of the problem,
whereas NOTARY deals with the whole thing. The drawback to NOTARY is that you
have to deploy it before it will work. But I think once list software supports
it there will be serious pressure to deploy it.
The sender verification step suffers from the problems #1 has only more so
--
people posting to lists *really* hate it and simply won't post if it is
used.
(I personally can tolerate #1 but won't accept this variant of it.) As for
Let me get this straight. A mechanism which detects and
unregistered, first time poster and sends a verification note which
requires nothing more than your hitting Reply is too much overhead?
Absolutely. You are not distinguishing between the case of a legitimate
first-time poster and a long time list subscriber who happens to be using an
address unknown to the list on this particular occasion.
I expect the latter to outnumber the former by at least 20 to 1, if not
more, on most lists.
Speaking now as an active participant, I would treat being deluged by such
confirmation requests every time I happen to use a different posting address as
a strong incentive not to participate any more on that list. I get too much
mail as it is. And I hope I would be able to resist the temptation to flame the
list maintainers to a nice toasty brown... No promises, however ;-)
For large, open lists this seems to me a reasonable compromise.
No, I'm not in love with it, but the incremental effort strikes me as
pretty reasonable. I guess we differ on our assessment.
Yup. This one is pretty much a nonstarter for me. I could see providing the
functionality for others to use (in fact I just realized we already provide
something similar).
having a moderator review messages received from people not subscribed to
the
list, this depends on having a moderator willing to perform the task. Such
moderator resources are in scarce supply. Also keep in mind that the burden
placed on the moderator is FAR greater than anticipated, as postings from
Yup. This is definitely an issue. That's why I would assume that
a list of verified, unregistered posters would be maintained. It should
reduce the steady-state overhead considerably. (No, not to zero.)
I missed this aspect of your proposal the first time around. It would be a
great improvement over only allowing recipients to post. But even with this in
place I don't think it would be sufficient.
The alternative approach of pestering a moderator with such things rather than
the original poster is another matter. This is the approach I recommend,
as a matter of fact.
The only thing I can think of is some sort of path validation by
scrutinzing Received headers and offhand I haven't a clue what the
algorithm needs to look like, if it is to be robust in the face of
alternate routing for legitimate mail.
Yee. MMDF attempted to do this at one point, with what could charitably
be termed "mixed results". There's lots of nuance here, and I'm not sure
it would ever prove to be a viable way to do business.
Ned