Leo + Python: the ultimate scripting tool: Conclusion
tjreedy at udel.edu
Thu Nov 13 20:55:51 CET 2003
"Stephen Horne" <steve at ninereeds.fsnet.co.uk> wrote in message
news:q9o6rv8rj8ilh2n9qrjou17kjhd9jbvg0f at 4ax.com...
> On Sun, 9 Nov 2003 21:29:35 -0500, "Terry Reedy" <tjreedy at udel.edu>
> >I will not beg you to read my bug report. Such a request is *NOT*
> >legitimate 'anti-junk-mail' measure.
> Is using that approval thing 'begging you to read...' to any greater
> degree than sending the e-mail in the first place?
To me, yes, most definitely, and especially for a short, two sentence
> My impression is that the 'reason' thing could just be 'Leo support
> request' or similar, for instance - enough to demonstrate that your
> e-mail is legitimate but hardly a chore.
But I do literally do not know what 'reason' thing any particular
person might want, or what an unknown person would even consider to be
a reason. Given my communication philosophy (choice, not reason) and
writing ability, I could find writing anything other that what I
originally wrote, already the best I could do, a paralyzing chore.
"What will Mr/Ms Recipient find acceptible? Will s/he even read what
I write or is this just a joke?" Etcetera.
I am somewhat flabbergasted that more people do not see the oddity of
"I will not read your first message (yet) but I will read a second
message from you in which you attempt to give me a reason that I find
'acceptible', according to my unknown-to-you whims, that I do read
your first message."
If someone is willing to read and evaluate message 2 to judge whether
the person is a suitable correspondant, then s/he could just as well
read (or just glance at) message 1 and make the same decision from the
better information of actual content.
In this case, the best 'reason' I could have given would have been to
repeat the self-justifying message itself. But that strikes me as
sort of somewhat dumb. Sort of like telling a secretary what I want
to say to his boss, except that the secretary is the boss. (Hmm.
Could be a funny sketch for a certain comedic troop.)
My objection is not just for email. I would find a
double-message-thru-a-third-party procedure just as odd for physical
letters or phone calls, even if under the guise of blocking junk mail
or junk phone calls, which I also get too many of.
> There would be a practical issue, of course, if you have access to
> e-mail but not to the web.
There are numerous people around the world with email-only accounts,
or email-only devices. There are also people who have web access but
pay by the byte. While not applicable to me personally, these
anti-universality practical issues *are* one of the reasons I will not
encourage such a system. Call it altruism if you will.
> Basically, I think you are overreacting to this.
'Beg' may have been a little strong, but otherwise I still don't
agree. Given that I hope to use Leo, I did not lightly or
thoughtlessly decide to openly fuss. My reasons goes far beyound a
mere 30-second annoyance (and have nothing to do with Leo or ER per
se). Discuss or even disagree if you will, but I think this
particular 'solution' is both socially and technically flawed.
To continue: I do not want any company to compile a list of *my*
correspondants. The US Post Office needs a court order (or at least
used to) to do the same. I am not about to give same to an unknown
entity I do not trust for free, especially when the procedure is
unnecessary and even counter to the supposed purpose.
As to the last. Decent filtering or automated verification by email
response to the challenge email, as other programs do, does not
require the intended
recipient to read anything but the original message, after
verification, and does *not* involve a third party to collect data
In another post, you wrote:
> If the approval is via e-mail then you have to accept e-mail from
> unknown people in order to recieve the approval requests in the
> place. That means you still recieve the spam.
No. As an alternative to rule/statistical filtering (which have
become quite effective), a whitelist program on your machine (or
corporate server) sets the message aside and sends a reply with a
coded subject line: "Hi new correspondant. Please confirm that you
are human and that you are the actual sender of the following". When,
and only when it gets the response, does it put it in your inbox.
> Of course you could make up some scheme with a standard subject line
> that is recognised as an authorisation request.
The program does this for you. All automated. Much easier, I think,
than reading 'please read me' requests.
A spam program could learn to respond to such challenge email, but
that would require an actual, persistent-for-a-few-hours and
potentially trackable mailbox rather than the fake or forged headers
now used. Such a program might just as well go to a site and enter a
reason like "I need your help', 'I have info for you', or even 'Viagra
at pharmo.tu'. In other words, any alternate message-to-human channel
could become an alternate spam channel!
In the reverse direction, if the verification site has ads on the
referred-to-page, then it would be a spam-to-original-sender channel
itself. Or the site could secretly sell the verified
active-and-correct addresses (market value, I've read, at least $20
each). Or a legitimate site could be hacked for its list. Or a site
could be set up by a spammer acting through a front. Run it
legitimately for a month, and then the deluge. Things like this are
easily predictable from past events. (For similar reasons, I would
also be wary of closed-source mail/spam software from unknowns.)
So I think any serious attack on junk email should aim at improving
local machine automated systems with minimal bother for human senders.
To foil better spam programs if/when deploed, something like the
following might work: "To verify sentience, click reply, enter on the
first line the number of legs that has a snake [or parrot, cat, ant,
or spider], and press send." in thousands of variations, and perhaps
misspellings, misspacings, and even anti-robot locutions like the
> steve at ninereeds dot fsnet dot co dot uk
Terry J. Reedy
More information about the Python-list