Re: How I deal with (false positive) IP-address blacklists...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How I deal with (false positive) IP-address blacklists...



Hi -

> From: "Dave CROCKER" <dhc2 at dcrocker.net>
> To: "Theodore Tso" <tytso at MIT.EDU>
> Cc: <ietf at 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 
> let's talk about it.  But I'm still not seeing how the thread you started qualifies.
...

The problem is a mis-match between the protocol model (and
the points for spam blocking it affords) and the economics of
actual use.

The debate about sender-vs-recipient responsibility for dealing
with false positives misses the point that the party usually
responsible for the blocking is under the control of neither
the sender nor the recipient.  I've spent enough time on hold to
far-away lands to be skeptical of claims that ISPs are really
that interested in resolving false positives, but I recognize that
the experience of individual users isn't considered valid data.

Ted's core point seems to be that that the "delivery value"
economic argument does not always align with the "sender
assumes responsibility for out-of-band-delivery when
blocked" model, particularly when the cost of out-of-band
delivery is far greater than the value of delivery to the sender,
no matter how badly the intended recipient who requested the
information might want it.

By looking only at the SMPT protocol exchange, rather than
the next-layer-up request-for-info followed by response, the
real use case is distorted.

Randy

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.