[EMAIL PROTECTED] wrote:
Like it or not, sample size reallly does matter. But if you really do prefer
individual anecdotal evidence, I'll point out that in practically every bogus
blocking incident I've seen of late, the fault lies not with an operation like
Spamhaus, but with some local
Schemes that attempt to assess the desirability of the email
to the recipient have been tried - personal whitelists,
personal Bayesian filters, etc. etc. In practice they haven't
worked all that well, perhaps due to the average user's
inability to capably and consistently perform such
(While Dave's response to this is exactly correct - notihng in my original
note had anything to do with sacrificing small scale setups - our failure
to discuss these matters sensibly has some very important implications for
small operators that deserve further comment.)
[EMAIL PROTECTED] wrote:
I wanted to send a message about my conclusion of this thread, as the
draft is now progressing to IESG review.
I sympathize with the desire to pull as much data as possible with a
simple request and no prior knowledge of what sessions exist. I think it
is obvious that with a better
On Tue, Dec 09, 2008 at 02:03:51AM -0500, Theodore Tso wrote:
Well, it blocked a legitimate e-mail message, so by definition the
rejection was false positive.
That's incorrect. Determining whether the rejection was a false positive
or true positive is the sole prerogative of the recipient,
Hi Ben,
Sorry for the delay..
Substantive Comments:
-- It is not clear to me why this is to be an informational RFC. It
seems to be defining protocol. If that protocol is not intended to
be a standard, then it would help to have an applicability
statement to that effect.
Good point,
On Tue, Dec 09, 2008 at 11:23:10AM -0800, Dave CROCKER wrote:
Evidently you believe that the anecdote you posted proves something, but
I am not sure what.
Some others have suggested that it proves something which, I strongly
suspect, is not what you had in mind.
Perhaps you can clarify
Theodore Tso wrote:
On Tue, Dec 09, 2008 at 11:23:10AM -0800, Dave CROCKER wrote:
Perhaps you can clarify the purpose of your note. How should it be
incorporated into the IETF's deliberations?
The point I was trying to make is that there seems to be an inherent
assumption by some people,
At 11:57 AM -0500 12/10/08, Theodore Tso wrote:
The point I was trying to make is that there seems to be an inherent
assumption by some people, perhaps because the people who make these
assumptions run large mail servers, that the problem with someone who
is wrongly blocked rests solely with the
Hi -
From: Dave CROCKER [EMAIL PROTECTED]
To: Theodore Tso [EMAIL PROTECTED]
Cc: ietf@ietf.org
Sent: Wednesday, December 10, 2008 10:23 AM
Subject: Re: How I deal with (false positive) IP-address blacklists...
...
Really: If there is a larger issue that the IETF can and should tackle, then
Paul Hoffman wrote:
At 11:57 AM -0500 12/10/08, Theodore Tso wrote:
The point I was trying to make is that there seems to be an inherent
assumption by some people, perhaps because the people who make these
assumptions run large mail servers, that the problem with someone who
is wrongly
[Apologies for the lateness of this review. I somehow mis-recorded the
due date. Here's my review hoping late is better than never.]
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
The IESG has received a request from the Routing Over Low power and
Lossy networks WG (roll) to consider the following document:
- 'Home Automation Routing Requirements in Low Power and Lossy Networks '
draft-ietf-roll-home-routing-reqs-06.txt as an Informational RFC
The IESG plans to make
The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'MANET Extension of OSPF using CDS Flooding '
draft-ietf-ospf-manet-mdr-03.txt as an Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'OSPF MPR Extension for Ad Hoc Networks '
draft-ietf-ospf-manet-mpr-03.txt as an Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'Extensions to OSPF to Support Mobile Ad Hoc Networking '
draft-ietf-ospf-manet-or-01.txt as an Experimental RFC
The IESG plans to make a decision in the next few weeks, and
The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'A Session Description Protocol (SDP) Offer/Answer Mechanism to
Enable File Transfer '
draft-ietf-mmusic-file-transfer-mech-09.txt as a Proposed Standard
The
The IESG has received a request from the Audio/Video Transport WG (avt)
to consider the following document:
- 'Post-Repair Loss RLE Report Block Type for RTCP XR '
draft-ietf-avt-post-repair-rtcp-xr-04.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
The IESG has received a request from an individual submitter to consider
the following document:
- 'Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions
for Supporting the PacketCable Distributed Call Signaling
Architecture'
draft-andreasen-sipping-rfc3603bis-07.txt as
A new Request for Comments is now available in online RFC libraries.
BCP 147
RFC 5407
Title: Example Call Flows of Race Conditions
in the Session Initiation Protocol (SIP)
Author: M. Hasebe, J. Koshiko,
20 matches
Mail list logo
