Fighting email spam and anti-UBE pointers

Archive-name: mail/anti-ube-pointer
Posting-Frequency: 2 times a month
Maintainer: Jari Aalto A T cante net

Announcement: "Bounces, Challenge-response systems, MTA, Bayesian tools (article pointer)"

Availability

FAQ archive is at http://www.faqs.org/faqs/

This message is an excerpt from bigger from Procmail Module
Library project's README.html document titled "Procmail
strategies against spam." available at
http://pm-lib.sourceforge.net/

The key points discussed in the document:

- Auto-replying or bouncing is considered a bad tactic
- MTA rejects can be abused and system administrators should
check their setup at least in regard to viruses.
- Challenge-Response system is based on false assumption that sender's
address can be used for authentication. It cannot and thus any C-R
system will contribute nothing else by amplifying the spam problem.

See picture http://pm-lib.sourceforge.net/pic/cr-system-joe-job.png

What should be done then?

- Bayesian tools are non-intrusive, harm no third parties
(in contrast to C-R), are easy to use and provide a good shelter.
- Battery of bayesian tools give even better shield due to
each program using a slightly different algorithm.

Many clarifying pictures are included:

- How address harvesting works
- How viruses should not be treated (at MTA level)
- Challenge-Response based authentication (overview)
- Challenge-Response system causing "Joe-Job"
- How MTA level UBE prevention works
- Procmail with battery of statistical tools

Table of contents:

1.0 Thoughts about increasing spam annoyance
1.1 Bouncing messages do no good
1.2 Rule based systems are not the solution
1.3 Challenge-Response systems make matters worse
1.3.1 Challenge-Response is not a doorbell but a
gun shooting decoys
1.3.2 Questioning Challenge-Response systems implementations
1.3.3 Summary - What are the effects of Challenge-Response
systems
1.4 Spam appearing in your yard - a story

2.0 A lightweight UBE block system with pure procmail
2.1 Suitable for accounts which ...
2.2 Where to put "pure procmail" UBE checks?
2.3 Using Procmail Module Library to fight spam

3.0 A heavyweight UBE blocking system
3.1 Advice for Debian Exim 4 mail system administrator
3.2 Advice for the normal account
3.3 Configuring Bayesian programs
3.4 A heavyweight spam catch setup using procmail

Some terminology

._UBE_ = Unsolicited Bulk Email
._UCE_ = (subset of UBE) Unsolicited Commercial Email

_Spam_ = Spam describes a particular kind of Usenet posting (and
canned spiced ham), but is now often used to describe many kinds of
inappropriate activities, including some email-related events. It
is technically incorrect to use "spam" to describe email abuse,
although attempting to correct the practice would amount to tilting
at windmills.

_Spam_ = definition by Erik Beckjord. "Some people decide that Spam
is anything you decide you want to ban if you can't handle the
intellectual load on a list." Remember, not to be confused with
real spam, which is unwanted bulk mail.

People are nowadays seeking a cure which will stop
or handle UBE. That can be easily done with procmail (under your
control) and with sendmail (by your sysadm). In order to select the
right strategy against UBE messages, you should read this section
and then decide how you will be using your procmail to deal with it.

Re: Fighting email spam and anti-UBE pointers

On comp.mail.misc, in , " (Jari Aalto+mail.procmail)" wrote:
>
>
> Archive-name: mail/anti-ube-pointer
> Posting-Frequency: 2 times a month
> Maintainer: Jari Aalto A T cante net
>
> Announcement: "Bounces, Challenge-response systems, MTA, Bayesian tools (article pointer)"
>
> Availability
>
> FAQ archive is at http://www.faqs.org/faqs/
>
> This message is an excerpt from bigger from Procmail Module
> Library project's README.html document titled "Procmail
> strategies against spam." available at
> http://pm-lib.sourceforge.net/
>
> The key points discussed in the document:
>
> - Auto-replying or bouncing is considered a bad tactic

That's absurd. Almost every corporation and organization in
the world does both.

You don't think that letting people know that their mail was
received (rather than being eaten by one of the dated spam
filters you recommend) or couldn't be delivered is a good idea?

> - Challenge-Response system is based on false assumption
> that sender's address can be used for authentication.

That's ridiculous. Challenge-Response systems are based upon the
assumption that spammers and trolls are using false return
addresses.

Which is true, 99.999% of the time.

Whoever produced this document is either extremely ignorant or
deliberately misleading the public.

Considering how many times they have been informed of its
erroneous content, the latter is the only reasonable conclusion.

Spammers and trolls HATE Challenge-Response systems, because theycannot beat them.

They can, however, beat the filters recommended in this post, and
do so all the time, because they are the world's foremost experts
in their use.

That's their _job/hobby_ They don't have anything else to do
with their time but figure out how to get their garbage in your
mailboxes.

And they can post whatever they want on the Usenet and the Web,
like anyone else.

Like this bi-weekly DISINFORMATIONAL article.

I wrote a simple Challenge-Response program that uses Procmail as
it's back end, and spam is no longer a part of my life. Period.

I don't even know when the spammers and trolls _try_ to get into
my mailboxes: Anonymous mail is rejected.

But no one I want to hear from has any problem reaching me.

Earthlink, as well as many other ISPs, offer Challenge-Response
systems as one of their basic spam-fighting tools.

Please Google the subject to get a real handle on it.




> - MTA rejects can be abused and system administrators should
> check their setup at least in regard to viruses.
> - Challenge-Response system is based on false assumption that sender's
> address can be used for authentication. It cannot and thus any C-R
> system will contribute nothing else by amplifying the spam problem.
>
> See picture http://pm-lib.sourceforge.net/pic/cr-system-joe-job.png
>
> What should be done then?
>
> - Bayesian tools are non-intrusive, harm no third parties
> (in contrast to C-R), are easy to use and provide a good shelter.
> - Battery of bayesian tools give even better shield due to
> each program using a slightly different algorithm.
>
> Many clarifying pictures are included:
>
> - How address harvesting works
> - How viruses should not be treated (at MTA level)
> - Challenge-Response based authentication (overview)
> - Challenge-Response system causing "Joe-Job"
> - How MTA level UBE prevention works
> - Procmail with battery of statistical tools
>
> Table of contents:
>
> 1.0 Thoughts about increasing spam annoyance
> 1.1 Bouncing messages do no good
> 1.2 Rule based systems are not the solution
> 1.3 Challenge-Response systems make matters worse
> 1.3.1 Challenge-Response is not a doorbell but a
> gun shooting decoys
> 1.3.2 Questioning Challenge-Response systems implementations
> 1.3.3 Summary - What are the effects of Challenge-Response
> systems
> 1.4 Spam appearing in your yard - a story
>
> 2.0 A lightweight UBE block system with pure procmail
> 2.1 Suitable for accounts which ...
> 2.2 Where to put "pure procmail" UBE checks?
> 2.3 Using Procmail Module Library to fight spam
>
> 3.0 A heavyweight UBE blocking system
> 3.1 Advice for Debian Exim 4 mail system administrator
> 3.2 Advice for the normal account
> 3.3 Configuring Bayesian programs
> 3.4 A heavyweight spam catch setup using procmail
>
> Some terminology
>
> ._UBE_ = Unsolicited Bulk Email
> ._UCE_ = (subset of UBE) Unsolicited Commercial Email
>
> _Spam_ = Spam describes a particular kind of Usenet posting (and
> canned spiced ham), but is now often used to describe many kinds of
> inappropriate activities, including some email-related events. It
> is technically incorrect to use "spam" to describe email abuse,
> although attempting to correct the practice would amount to tilting
> at windmills.
>
> _Spam_ = definition by Erik Beckjord. "Some people decide that Spam
> is anything you decide you want to ban if you can't handle the
> intellectual load on a list." Remember, not to be confused with
> real spam, which is unwanted bulk mail.
>
> People are nowadays seeking a cure which will stop
> or handle UBE. That can be easily done with procmail (under your
> control) and with sendmail (by your sysadm). In order to select the
> right strategy against UBE messages, you should read this section
> and then decide how you will be using your procmail to deal with it.
>
>


AC

alanconnor
AT
earthlink
DOT net

Re: Fighting email spam and anti-UBE pointers

On Mon, 21 Mar 2005, C-R Systems wrote:
> On comp.mail.misc, in , " (Jari Aalto+mail.procmail)" wrote:
> > Archive-name: mail/anti-ube-pointer
> > Posting-Frequency: 2 times a month
> > Maintainer: Jari Aalto A T cante net
> >
> > Announcement: "Bounces, Challenge-response systems, MTA, Bayesian tools (article pointer)"
> >
> > Availability
> >
> > FAQ archive is at http://www.faqs.org/faqs/
> >
> > This message is an excerpt from bigger from Procmail Module
> > Library project's README.html document titled "Procmail
> > strategies against spam." available at
> > http://pm-lib.sourceforge.net/
> >
> > The key points discussed in the document:
> >
> > - Auto-replying or bouncing is considered a bad tactic
>
> That's absurd. Almost every corporation and organization in
> the world does both.
>
> You don't think that letting people know that their mail was
> received (rather than being eaten by one of the dated spam
> filters you recommend) or couldn't be delivered is a good idea?

That's what the Delivery Status Notification message subsystem is for.

> > - Challenge-Response system is based on false assumption
> > that sender's address can be used for authentication.
>
> That's ridiculous. Challenge-Response systems are based upon the
> assumption that spammers and trolls are using false return
> addresses. Which is true, 99.999% of the time.

Then why send the challenge in the first place if you KNOW that the sender
never originated the message? There's no reason to challege it - just discard
(or bounce or reject) it to begin with.

> Whoever produced this document is either extremely ignorant or
> deliberately misleading the public.

Like your opinion is any better. It's even more misguided, AC.

> Considering how many times they have been informed of its
> erroneous content, the latter is the only reasonable conclusion.

And no matter how many times you have been informed of the ABUSE caused by C-R
systems and how C-R systems themselves CAN BE ABUSED, you insist on your insane
conclusions.

> Spammers and trolls HATE Challenge-Response systems, because they cannot beat
> them.

Legitimate e-mail users HATE C-R systems too, because of the harassment they
cause and the abuse that spammers can employ them to cause.

> ...
> Like this bi-weekly DISINFORMATIONAL article.

Talking about your own system, I see.

> I wrote a simple Challenge-Response program that uses Procmail as
> it's back end, and spam is no longer a part of my life. Period.

You make spam everyone else's problem by becomming a spammer relay station.

> But no one I want to hear from has any problem reaching me.

Since that count of people is zero, it doesn't matter.

> Earthlink, as well as many other ISPs, offer Challenge-Response
> systems as one of their basic spam-fighting tools.

And they have been blacklisted for doing so.

Re: Fighting email spam and anti-UBE pointers

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-commodore.email-scan.com-31778-1111407608-0002
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Beavis writes:

> On comp.mail.misc, in , " (Jari Aalto+mail.procmail)" wrote:
>>
>>
>> This message is an excerpt from bigger from Procmail Module
>> Library project's README.html document titled "Procmail
>> strategies against spam." available at
>> http://pm-lib.sourceforge.net/
>>
>> The key points discussed in the document:
>>
>> - Auto-replying or bouncing is considered a bad tactic
>
> That's absurd. Almost every corporation and organization in
> the world does both.

No, Beavis, it's not absurd. I tell you what is really absurd: it's
observing a well-known kookbag arguing with a script-posted article.

> You don't think that letting people know that their mail was
> received (rather than being eaten by one of the dated spam
> filters you recommend) or couldn't be delivered is a good idea?

Beavis: you let people know that the message is undeliverable by refusing to
accept it in the first place, by rejecting the attempt to deliver the
message via SMTP, instead of accepting it, and bouncing it.

I bet a 1,000 quatloos that you have no idea what this means.

>> - Challenge-Response system is based on false assumption
>> that sender's address can be used for authentication.
>
> That's ridiculous.

Beavis: please explain how you manage to authenticate the validity of the
sender's address. I guess there is a purpose why you post random excerpts
from your procmail logs, for no good reason, occasionally. Next time you do
that, look at them yourself, then figure out whether the return addresses on
those messages are valid, or not.

> But no one I want to hear from has any problem reaching me.

Nobody wants to hear from your, Beavis.



--=_mimegpg-commodore.email-scan.com-31778-1111407608-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCPrv4x9p3GYHlUOIRAnUWAJ9KiKpjbjcBrjgeauNMyV1T0skRGQCc CYFt
oD8MvXTE6UwkN7FDaKvU6+A=
=MgP9
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-31778-1111407608-0002--

Re: Fighting email spam and anti-UBE pointers

On Mon, 21 Mar 2005 06:20:09 -0600, Sam wrote:
>
>> But no one I want to hear from has any problem reaching me.
>
> Nobody wants to hear from your, Beavis.

Now, that's just not true. Just the other day, I was having tea with Xena,
Bigfoot and the Easter Bunny. All of them have been emailing Alan, but the
replies are always in X's.

If he throws in some O's, I'd guess he's written a mail processor that
also plays tic-tac-toe.

--
_________________________________________
NetworkElf: Super Genius, Computer Guy, Harley Owner!
Blindly serving the covert purposes of the
criminal-minded maniac behind Spews since 2003.

Re: Fighting email spam and anti-UBE pointers

On comp.mail.misc, in , "Alan Connor" wrote:
>
>



hehe

I multi-posted this to the 3 dozen most-read mail newsgroups.

(wrote a script that makes it easy as pie)

All "jari" posted to was news.answers (which didn't even post
it) and this group, and comp.answers (which very few people
read).

Spammers just aren't very bright.

AC

--
Genuine Usenet Kook
http://angel.1jh.com./nanae/kooks/alanconnor.html