ietf
[Top] [All Lists]

More anti-spam (was: Re: several messages)

2008-11-12 16:01:37


--On Wednesday, 12 November, 2008 12:40 -0800 David Romerstein
<romer(_at_)hanov3r(_dot_)com> wrote:

[roughly 37 bajillion To: addresses removed]

On Wed, 12 Nov 2008, Dean Anderson wrote:
On Wed, 12 Nov 2008, David Romerstein wrote:

If they don't notice the dropped subscription, I'd say
they're not negatively impacted.

Hmm. Wonder if you'd say the same if it was your bank
account, or your house robbed: "Gee your honor, I waited and
waited, and nobody noticed, so it must be ok to take his
money and possessions."

You do realize that, in this context, your 'argument' makes no
sense, right?

The point is that, someday, long after the opportunity to
participate has passed, they find out they've been dropped.

I'm on many mailing lists. I participate in all of them. I am
aware of the approximate volume of mail I get from them
everyday, at least by orders of magnitude. If a list that
normally sees 20-30 emails a day doesn't have any for a day,
I'm likely to start investigating. That may make me unusual;
based on my experiences blocking spam at A Large ISP several
years ago, though, I suspect that I am not. People complain to
their postmasters *vociferously* when expected mail is not
received, and that shows that those emails have value to them.

David,

I'm on many mailing lists, at several different addresses.  Many
of them, including some IETF ones, operate in start-and-stop
mode, i.e., it is a common pattern for there to be a large
volume of messages over a short period of time, then nothing for
weeks.  Requiring that I notice when I am not being sent mail
from one of those lists borders on the absurd.

I also have arrangements with various financial institutions who
send out alerts under a variety of circumstances.  If things are
normal, I see no alerts, ever.  Expecting that I notice
non-receipt of a message from them that is intended to give me
timely notification of an event borders on the ludicrous.
Expecting that I notice non-receipt of a revised prospectus or
proxy statement is almost equally problematic.

Then there is the mailing list case you advocate in which the
sender to the list, or the list maintainer, is expected to use
an out-of-band (non-email) mechanism, such as a phone call, to
tell the end user that something didn't go through.  In addition
to the obvious privacy concerns (I don't know who is on the IETF
list, have no way to find out, and, if I did find out, might not
be able to match addresses to people and their other contact
information and identity credentials) this comes close to
requiring authentication of those who subscribe to email lists,
even if they merely watch the list but don't ever post.  I've
got some fairly severe problems with that idea.  I note that it
is not even a requirement for postal mail: e.g., if I subscribe
to a newsletter you operate that is distributed through the
post, and give a post office box address, in the US it is a
felony for someone at the post office to supply you with my
other contact information (to save Dean, with whom I usually
disagree on these matters, the trouble), it is also a felony if
someone decides that they don't like me or my sanitary habits,
and, on that basis, refuses to deliver mail addressed to me.

While I'm not a fan of RBLs, I still see the debate about their
usability as being one of tradeoffs (and the debate about
whether a few ASIRG documents should be standardized as about
IETF operational philosophy and procedures much more than about
the specific content of those documents).  But, when you or
others start making arguments that sound like a few false
positives and consequent lost mail are ok, and especially if you
also take the position that such messages are the expected
recepient's fault (or at least exclusively that recipient's
problem), then I stop seeing tradeoffs and start seeing a much
more severe threat to the Internet's mail environment than that
posed by the spammers.

   john



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>