The WWW-page mailto approach to spam
Timo Salmi
replace) the public email password system which I have descibed in
Foiling Spam with an Email Password System
http://www.uwasa.fi/~ts/info/spamfoil.html
One could call this the WWW-page variant or even the Guestbook
rendition. It goes as follows: As you know, in building a WWW
page the HTML code for sending email via the WWW page is
<A HREF="mailto:my...@myhost.mydom">Click to send me email</A>
If one changes it to
<A HREF="mailto:my...@myhost.mydom(FirstName LastName Passwd)">
Click to send me email</A>
Then the procmail recipe for accepting such email is simply
:0:
* ^To:.*FirstName.*LastName.*Passwd
${DEFAULT}
Naturally, this method is not a guarantee against spam. But it is
surprisingly effective in actual practice. I have used this
complementary variation along with my main email password spam
foiling method on several on my web pages since January 1998. Almost
no spam has resulted via this route (either).
The big advantage of this method is that it (at least to an extent)
avoids the first contact conundrum if both the parties are using a
challenge-response email password system.
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Timo's procmail tips at http://www.uwasa.fi/~ts/info/proctips.html
Alan Connor
My Hero!
Alan (who STILL can't get a mail through to you.....???? All my headers are
a-okay as far as I can tell. From, From:, and Reply-To all give my actual
email address....)
--
For Linux/Bash users: Eliminate spam from your life
with Password-Protected-Mailboxes. I have the scripts
and docs for anyone that wants them.
David F. Skoll
> My Hero!
> Alan (who STILL can't get a mail through to you.....????
:-)
Either PPM isn't the best thing since sliced bread, or Timo Salmi doesn't
want to talk to you. :-)
--
Timo Salmi
> Alan Connor wrote:
> > Alan (who STILL can't get a mail through to you.....???? [Timo Salmi]
> Either PPM isn't the best thing since sliced bread, or Timo Salmi doesn't
> want to talk to you. :-)
The are several possibilities including:
Alan's email does not reach me. Actually, I have not noticed
anything from Alan in my logs. But I am mostly scanning them only
superficially.
My automated password challenge does not reach Alan.
Be that as may, I usually prefer anyway to discuss these computer
related ideas on the Usenet news. As far as possible, I wish to
reserve employing email for my actual profession, and for my private
life, only.
Alan Connor
> David F. Skoll <d...@roaringpenguin.com> wrote:
>> Alan Connor wrote:
>> > Alan (who STILL can't get a mail through to you.....???? [Timo Salmi]
>
>> Either PPM isn't the best thing since sliced bread, or Timo Salmi doesn't
>> want to talk to you. :-)
>
Shut up you dork. There's no need to add to the long list of incoherent and
irrelevant posts you have made on the subject.
> The are several possibilities including:
>
> Alan's email does not reach me. Actually, I have not noticed
> anything from Alan in my logs. But I am mostly scanning them only
> superficially.
>
> My automated password challenge does not reach Alan.
>
> Be that as may, I usually prefer anyway to discuss these computer
> related ideas on the Usenet news. As far as possible, I wish to
> reserve employing email for my actual profession, and for my private
> life, only.
>
Yes, of course. Makes sense.
> All the best, Timo
>
Well, I haven't actually been flooding you with mails, Professor. Tried twice,
once before and after I was 'white-listed'...I correspond with people in
Australia, France, England, and Ireland all the time......
My question is about lockfiles in procmail. (Or, perhaps, lockfiles in general.)
Is there really a huge difference between...
:0
* ^From.*foo
mailbox
:0:
* ^From.*foo
mailbox
:0: foo.lock
* ^From.*foo
mailbox
....if so, what, and which choice is best for ordinary pass-list entries?
As it stands, the only entries in my .procmailrc that use the lockfile syntax
are the main one that returns the request for a password (it has a named
lockfile, as you know, having written it...) and the final one:
:0:
/dev/null
Thank you very much.
Alan
David F. Skoll
> Shut up you dork. There's no need to add to the long list of incoherent
> and irrelevant posts you have made on the subject.
:-)
I thought I was in your kill file.
I guess you can't resist! :-)
--
Timo Salmi
> Is there really a huge difference between...
>
> :0
> * ^From.*foo
> mailbox
> :0:
> * ^From.*foo
> mailbox
Lockfile name provided my procmail. The most common choice.
> :0: foo.lock
> * ^From.*foo
> mailbox
Lockfile named by the user. Usually used in connection with pipes,
when procmail will not do it for the user.
> :0:
> /dev/null
Procmail manuals specifically warn against using a lock file in
connection with /dev/null. Someone else may recall theaccurate
reason.
Alan Connor
> Alan Connor <alanc...@earthlink.net> wrote:
>> Is there really a huge difference between...
>>
>> :0
>> * ^From.*foo
>> mailbox
> Lockfile missing. Problems if too much email arrive simultaneously.
>
>> :0:
>> * ^From.*foo
>> mailbox
>
> Lockfile name provided my procmail. The most common choice.
>
>> :0: foo.lock
>> * ^From.*foo
>> mailbox
>
> Lockfile named by the user. Usually used in connection with pipes,
> when procmail will not do it for the user.
>
>> :0:
>> /dev/null
>
> Procmail manuals specifically warn against using a lock file in
> connection with /dev/null. Someone else may recall theaccurate
> reason.
>
> All the best, Timo
>
Many thanks, Professor. Saved to my procmail directory .I am currently studying your various relevant webpages and learning a great deal.
Alan
--
Blinky the Shark
> Alan Connor wrote:
>:-)
You can blame us over in news.software.readers. We tried to contain
him, but he got past the no-pest strips.
--
Blinky Linux RU 297263
Spam: The Boulder Pledge http://snurl.com/bpledge
Digest: Best of Internet Oracularities http://snurl.com/dig_oracle
Alan Connor
> David F. Skoll wrote:
>
>> Alan Connor wrote:
>
>>> Shut up you dork. There's no need to add to the long list of incoherent
>>> and irrelevant posts you have made on the subject.
>
>>:-)
>
>> I thought I was in your kill file.
>
>> I guess you can't resist! :-)
>
Once again, David F.S., you demonstrate your inability to think clearly.
That response was in a post to someone else who had responded to you.
> You can blame us over in news.software.readers. We tried to contain
> him, but he got past the no-pest strips.
>
I guess I'm going to have to killfile Blinky from EVERY group, instead of
just news.software.readers. Troll are SO damned boring.
But good company for DFS. Birds-of-a-feather.......
Alan
--
For Linux/Bash users: Eliminate spam from your life
with Password-Protected-Mailboxes. See the post
PPM1.b on comp.mail.misc.
Sahil Tandon
> Procmail manuals specifically warn against using a lock file in
> connection with /dev/null. Someone else may recall theaccurate
> reason.
Some excerpts from the Procmail Mini-FAQ should clarify:
| Rule of thumb: Use file locking when delivering to a file. Don't use file
| locking when delivering to /dev/null (because then it doesn't matter if the
| message gets mangled, and you might not have the permission to acquire a lock
| on a device), forwarding to another address, or piping into a program. A
| pipeline which ends up appending to a file should still use a lock, of course,
| since there is the same race condition as when delivering straight to a file.
| Attempting to lock things you shouldn't lock (such as /dev/null, or using your
| actual inbox as the lock file for itself :-) can leave Procmail hanging and
| consuming lots of resources.
Still, there is hope for those who continue to lock /dev/null recipes:
| Attempting to lock /dev/null is special-cased in newer versions of Procmail
| so that shouldn't be dangerous.
Regards,
--
Sahil Tandon <sa...@despammed.com>
http://people.brandeis.edu/~sahil
David F. Skoll
> That response was in a post to someone else who had responded to you.
You need decent software that can kill entire threads, then.
I have such software (for mailing lists, alas, not newsreaders.)
--