lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <08f301c6d2cb$ea2cdac0$294b82ce@stuartm>
Date:	Thu, 7 Sep 2006 18:21:06 -0400
From:	"Stuart MacDonald" <stuartm@...necttech.com>
To:	"'Chase Venters'" <chase.venters@...entec.com>
Cc:	"'Krzysztof Halasa'" <khc@...waw.pl>, <ellis@...nics.net>,
	"'Willy Tarreau'" <w@....eu>, <linux-kernel@...r.kernel.org>
Subject: RE: [OT] RE: bogofilter ate 3/5

From: Chase Venters [mailto:chase.venters@...entec.com] 
> So what is the SpamCop RBL data used for then?

SpamCop uses it on their own mail service to flag messages as
potential spam and filter those out to a junk folder.

They also publish the list publicly.

So, SpamCop is blocking 0 emails.

As for third parties looking at their RBL, SpamCop specifically
recommends that the list *not* be used for blocking:
http://www.spamcop.net/fom-serve/cache/291.html

> (1) The mail _would_ be solicited because you asked for it on 
> my behalf;

So you'll be sending me your snail mail address then? Thanks.

> permission. Phony permission, perhaps, but permission nonetheless...

False permission is no permission at all. That's a widely recognised
concept; in law, life and the internet.

> On Thu, 7 Sep 2006, Stuart MacDonald wrote:
> > Things change.
> 
> Yes, and eventually Internet mail will grow up and forgery 

SMTP is growing up *right now*. The reconfig of servers to not send
unsolicted bounces/etc is part of the growing-up-ness.

The following fall into two categories:

> 1. No more bounce messages
> 4. No more deferral messages

Servers can be configed to not send these. To those whose systems are
set up in such a manner to require accepting the message before
delivery, to paraphrase Chase, "(2) Spammers would be responsible for
your misery, not the parties rejecting your bounces".

> 2. No more "Your message has been queued for moderator 
> approval" messages
> 3. No more "Thanks for contacting CrapCo, your support ticket 
> # is 238417" 
> messages
> 5. No more vacation mail
> 6. No more challenge/response systems
> 7. No more mailing lists that you can sign up to by sending mail to 
> subscribe@...t.org or majordomo@...t.org; all subscription and 
> unsubscription must be done through web interfaces

All of these should be sent by a human.

> can turn all auto-response systems off completely.

Yep. That's the growing up you were looking for earlier.

It looks like we disagree on the method of change required. That's
life.

..Stu

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ