RE: Re: [Dev-C++] .net langwijs

As always happens, once we make a system sufficiently widespread to be
useful, spammers will find a way to compromise it. The Yahoo System and SPF
do not do much about the business of shoddy / scumbag spam-supporting ISPs,
from whence the majority of the spam is sent. The shoddy ISPs will continue
to proliferate with their countless new domain names and IP addresses for
servers. They will sign their DNS / add DNS records as needed to allow them
to continue profiting from others' bad behvavior. Therefore I think they
will be more or less useless. Technical costs will never stop spam because
it's too simple to circumvent them. The only way to stop spam would have to
generate some kind of substantial economic cost. These systems are like
every other anti-spam system ever devised. They increase the complexity of
sending and receiving normal everyday mail while doing essentially nothing
to spam.

Clearly, sir, if "the industry" is headed toward using these solutions
(unlikely, SPF has been around forever), "the industry" is making a big
mistake. It will increase costs and will not substantially interfere with
spam. I can safely say that there is no better anti-spam system than the
delete key on your keyboard. All of these other "solutions" are broken and
do not address the fundamental reality of how spammers operate.


From spf.pobox.com:
"SPF fights return-path address forgery and makes it easier to identify
spoofs. Domain owners identify sending mail servers in DNS. SMTP receivers
verify the envelope sender address against this information, and can
distinguish authentic messages from forgeries before any message data is
transmitted."

From antispam.yahoo.com Domain Keys FAQ:
"Won't spammers just sign their messages with DomainKeys?

Hopefully! If they do, they'll make it easier for the Internet community to
isolate and drop/quarantine their messages using the methods described above
in "How will this help stop spam?" Eliminating the uncertainty of "did this
email really come from the domain example.com?" will facilitate a whole
range of anti-spam solutions."

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...]On Behalf Of Thomas
Smith
Sent: Tuesday, July 19, 2005 12:47 PM
To: 'Josh McFarlane'; 'Thomas Smith'
Cc: dev...@li...
Subject: RE: Re: [Dev-C++] .net langwijs


You have a good point, Josh. I hadn't considered the whole foreign email
situation you mentioned... Beyond that...

I personally advocate the challenge-response systems and use one myself.
They aren't without their flaws but the value they offer outweighs those
flaws. Further, there are architectures that minimize the burden on those
you email frequently (check out a-s-k.sf.net) buy incorporating
auto-whitelisting techniques that are impossible for spammers to detect
using their automated email-gathering tools (I have yet to hear of a
compromise of the ASK system).

Further, if you look at the direction the industry is headed you'd notice
that everyone will eventually be using some form of sender-based
authentication. There are several systems out there (Yahoo Domain Keys
quickly comes to mind... So does SPF). Though these systems differ somewhat
from a typical challenge-response system, the concept is the same--in order
to STOP spam, we must force the sender to verify they are valid users. I
don't think it matters much if that end is achieved using a "challenge"
email, or by verifying a valid MX server exists for the sender's domain, or
that the sender's MX server accepts inbound DSNs (similar to what
milter-sender does), and so on.

So, I absolutely advocate sender verification in the war against spam since
spammers have to use fake emails to conceal their identity and thus aren't
able to respond to such verifications.

You also mentioned "email" congestion. What about network congestion
introduced by checking blacklists or verifying Domain Keys?

No system is, or will ever, be perfect. I think it's a matter of choosing
the lesser of the available evils. 

-----Original Message-----
From: Josh McFarlane [mailto:da...@gm...] 
Sent: Tuesday, July 19, 2005 12:18 PM
To: Thomas Smith
Cc: dev...@li...
Subject: Re: Re: [Dev-C++] .net langwijs

On 7/19/05, Thomas Smith <ml...@hp...> wrote:
>  
> Well, there is one other possible solution... since the list admin doesn't
> seem interested in doing anything about this. 
>   
> If you just do what the email is requesting (click the link and fill out
the
> requested "box" by entering the five characters in the picture) you
wouldn't
> receive any further challenge emails from that person.

Except it goes against my fundamental values, as well as logs my email
address is some foreign mail server, which could possibly in the
future distribute it to spammers. Not to mention I abhor the challenge
email filter system, as it does nothing to combat the network
congestion that spam generates, and only further increases the
problem. Instead of helping to fix the spam problem, the mail servers
that employ it take the easy way out, and simply generate a message
for every incoming.

Be nice if the world worked that way. How would you feel if every
phone message you left, you had to call another number to confirm that
you really are who you are. Or want to pay a bill? Sure, just mail it
and then go in person to verify that you really sent the letter.

That's the absurdity of it to me.

-- 
Josh McFarlane

"Peace cannot be kept by force. It can only be achieved by understanding."
-Albert Einstein



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
___________________________________________________________________
The information contained in this message and any attachment may be
proprietary, confidential, and privileged or subject to the work
product doctrine and thus protected from disclosure.  If the reader
of this message is not the intended recipient, or an employee or
agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify me
immediately by replying to this message and deleting it and all
copies and backups thereof.  Thank you.