Dean,
--On 17. desember 2003 16:01 -0500 Dean Anderson [EMAIL PROTECTED] wrote:
This is ridiculous. The IETF is not getting a lot of spam, so adding
SpamAssassin headers is a solution in need of a problem.
the reason you don't see a lot of spam on IETF lists is because it's sent
to the list
These are the facts.
On Wednesday 17 December 2003 16:01, Dean Anderson wrote:
This is ridiculous. The IETF is not getting a lot of spam, so adding
SpamAssassin headers is a solution in need of a problem.
a lot is a subjective term. Also, unless you are sniffing the traffic into
our
On Wed, 17 Dec 2003, Harald Tveit Alvestrand wrote:
--On 17. desember 2003 16:01 -0500 Dean Anderson [EMAIL PROTECTED] wrote:
This is ridiculous. The IETF is not getting a lot of spam, so adding
SpamAssassin headers is a solution in need of a problem.
the reason you don't see a lot of
Brett Thorson wrote:
The goal is to reduce spam, and reduce the human intervention needed to reduce
spam.
Right. I support the secretariat's efforts to reduce spam and
associated management effort on the IETF lists. Personally, I
have a good experience with SpamAssissin, so to me the technical
Mark Allman wrote:
A tag in the subject line is clearly overdue. But, if we're going to do
it, let's do it right. Please use [IETF] not [ietf] because it's
more befitting of a proper acronym.
Just what we need, a mailing list that SHOUTS.
(Then again, for this list, maybe it constitutes fair
Harald Tveit Alvestrand [EMAIL PROTECTED] wrote:
the reason you don't see a lot of spam on IETF lists is because it's
sent to the list administrators, and they filter it by hand.
Clearly, this cannot continue (unless we come up with some way to
pay people to perform this service).
The
the reason you don't see a lot of spam on IETF lists is because it's
sent to the list administrators, and they filter it by hand.
The chief beneficiaries of automatic spam detection and deletion in
the current IETF setup is the list administrators.
I'm one of those list administrators and I can
Keith,
the reason the secretariat is doing this in stages is exactly because we
want to see how big the false-positive issue is.
I currently personally use Mailman 2.60 with Bayesian filtering and
close-to-default rules; it seems to run at a very low rate of false
positives.
--On 18.
Keith and others,
While...
(1) I agree that this (and any SpamAssassin or other
header-insertion or filtering) would, ideally, better be
done as a per-subscriber optional feature, and
(2) I recognize that, if for some reason (unfathomable
to me,
On Thu, 18 Dec 2003, Keith Moore wrote:
I'm one of those list administrators and I can attest that having spam
flood the review queues of the mailing lists is a huge problem.
Ahh. Mail from non-subscribers that has to be reviewed. SpamBayes or
other content filters would be a far better
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Harald Tveit Alvestrand wrote:
| Keith,
|
| the reason the secretariat is doing this in stages is exactly because we
| want to see how big the false-positive issue is.
|
| I currently personally use Mailman 2.60 with Bayesian filtering and
|
From lines and Reply-to and whatever are headers that are meant to
be processed by computers. So, you can say all you want about how
dumb MUAs do or do not process these (and how intermediate mail
servers should keep their mits off). Now, humans use these lines,
too. So, call them dual
I work on an approach to block spam with a database of hash (md5) string of
spam email:
1) Reporting a verified spam to the database server on the web
2) the mail client check incoming mail, generate a hash string send to and
verify the presence on the server, is yes block email.
3) download a hot
On 18 Dec 2003, at 13:10, escom wrote:
I work on an approach to block spam with a database of hash (md5)
string of
spam email:
1) Reporting a verified spam to the database server on the web
2) the mail client check incoming mail, generate a hash string send to
and
verify the presence on the
From: escom [EMAIL PROTECTED]
I work on an approach to block spam with a database of hash (md5) string of
spam email:
1) Reporting a verified spam to the database server on the web
2) the mail client check incoming mail, generate a hash string send to and
verify the presence on the server,
On Thu, 18 Dec 2003 13:07:24 -0500
Keith Moore [EMAIL PROTECTED] wrote:
I'm a bit surprised at the frequency at which people who claim to be
networking protocol engineers fail to appreciate the benefits of clean
separation-of-function and layering.
Hopefully the drawbacks are appreciated
Thus spake John Stracke [EMAIL PROTECTED]
Modifying the Subject: line is a Bad Thing; it invalidates digital
signatures. We're never going to get widespread use of signed email as
long as we have pieces of mail infrastructure munging messages to make
signatures useless.
Signed email already
escom wrote:
I work on an approach to block spam with a database of hash (md5) string of
spam email:
1) Reporting a verified spam to the database server on the web
2) the mail client check incoming mail, generate a hash string send to and
verify the presence on the server, is yes block email.
3)
From: John Stracke [EMAIL PROTECTED]
I work on an approach to block spam with a database of hash (md5) string of
spam email:
...
It's been done, and the spammers have already evolved to get around it:
they randomize the messages so that the hashes don't match.
Unless you are mean naive
Stephen Sprunk wrote:
Thus spake John Stracke [EMAIL PROTECTED]
Modifying the Subject: line is a Bad Thing; it invalidates digital
signatures. We're never going to get widespread use of signed email as
long as we have pieces of mail infrastructure munging messages to make
signatures
John,
Trying to make this response a brief one, and hopefully the last message
I need to write on this topic for a while.
1) While I generally support reducing secretariat workload when
possible, I don't think it follows that it's to our advantage to let
them automate anything they can sensibly
Dean Anderson wrote:
Mostly, this is due to the revenge oriented blacklists that it uses.
You are aware that's it's trivial to disable all the blacklist testing in
the config, aren't you? SpamAssassin is extremely configurable.
-- Jake Nelson
On Thu, 18 Dec 2003 13:07:24 -0500
Keith Moore [EMAIL PROTECTED] wrote:
I'm a bit surprised at the frequency at which people who claim to be
networking protocol engineers fail to appreciate the benefits of
clean separation-of-function and layering.
Hopefully the drawbacks are
The subject line, on the other hand, is just for people.
Book titles are for people, too. Does that mean that it's okay for a
bookseller or library to change the titles on books, in order to help
the consumer indentify where they came from?
Um, my library slaps a helpful identification
Keith-
Putting [foo] in the subject header is just another example of this
trend. Sure, it might be useful to people with dysfunctional MUAs,
and there are a lot of those people out there. There were once a lot
of people whose MUAs couldn't do reply all, too.
This is just wrong.
From
The problem with this analysis is that it assigns greater value to
contributions from subscribers than to contributions from
non-subscribers. But often the failure to accept clues from
outsiders causes working groups to do harm - and filtering messages
in the #2 category increases this
Vernon Schryver [EMAIL PROTECTED] wrote:
Concerning false positives for this mailing list--it would be wise to
define what mail is legitimate. In many places, you must accept at
least 99.9% of all even remotely legitimate mail. However, this context
is different. Here a boolean good/spam
From: John Leslie [EMAIL PROTECTED]
...
This is where I must disagree. Whitelisting something as easily
forged as the From address is simply wrong -- and if it is published
rule, we're sure to see spammers forging whitelisted From addresses
as their standard operating practice.
As is
On Wed, 17 Dec 2003 23:10:43 -0500, Bill Cunningham wrote:
Now that the federal government has taken some steps in regulating spam,
does that mean that a technical need as the IETF would look for, isn't
needed?Maybe the Spam should be forgot about.
Bill has the CMOS backup battery failed in your
On Thu, Dec 18, 2003 at 03:39:58PM -0500, Keith Moore wrote:
The problem with this analysis is that it assigns greater value to
contributions from subscribers than to contributions from
non-subscribers. But often the failure to accept clues from
outsiders causes working groups to do harm
But often the failure to accept clues from
outsiders causes working groups to do harm
I don't believe this is true, for any normal definition of often.
Occasionally might be believable.
if I look at why working groups do harm, the failure to accept clues
from outsiders does seem to crop up
In following up the discussion of the IAB Advisory Committee
output, on December 1:
http://www.ietf.org/mail-archive/ietf-announce/Current/msg27463.html
I noted that I would endeavour to post monthly updates on progress,
around mid-month. It's only been 2 weeks, but I thought it
was important to
Vernon Schryver [EMAIL PROTECTED] wrote:
From: John Leslie [EMAIL PROTECTED]
This is where I must disagree. Whitelisting something as easily
forged as the From address is simply wrong -- and if it is published
rule, we're sure to see spammers forging whitelisted From addresses
as their
It just strikes me as highly unlikely that a WG would ever change
course
because of what would look like random comments from outsiders -- it's
not consistent with the dynamics of a WG, or with human nature.
and that just might be one of our biggest problems, in a nutshell.
On Thu, 18 Dec 2003 13:19:29 EST, Mark Allman said:
Um, my library slaps a helpful identification tag on the spine of every
book to help me find it. Your analogy, man ...
A quick sampling of 15 books from our local public library shows that:
a) All 15 have spine tags for on the shelves and
35 matches
Mail list logo
