Re: Inexpensive anti-spamware/anti-verminware tactic

Jonathan de Boyne Pollard <[email protected]> wrote:
> JR> Firstly, "cost to sender". 
> 
> And here's that one side. 

No. I discussed several sides. You can't complain I *included*
discussion of this one.

> JR> UBE only exists because the cost to sender is low. 
> 
> This is a fallacy.  Unsolicited bulk mail exists in systems where the cost 
> to the sender is high, such as the physical mail system.  There's just 
> _less_ of it.  

Indeed. So as the cost of sending increases, the amount of it tends to
zero. If as little of my day was taken up with handling UBE as is
taken up with handling junkmail, I would not care about UBE at all.

> You haven't been following the discussion.

Wrong. You are leaping to conclusions. I did not suggest that the cost
of sending should be increased. However it is far from clear that
*decreasing* it is in any way helpful.

> James is stuck on the erroneous idea, that you repeat, that penalising 
> senders is the goal.  But it is not.

I neither said nor implied any such thing. Try to address the points
I actually make, rather than inventing other points that you would
prefer I had made since you think you can refute them more easily.

Besides which, even if I *had* said something like that, which
I didn't, increasing the costs to spammers would clearly reduce spam.
You have not presented any arguments as to why this is bad.

> They have that information right now, with web bugs, messages with external 
> content, and "click here to secretly tell us you read this even though you
> might think that you are doing something else" hyperlinks.

Not from me they don't. If I was using IM2000 they would.

> Tracking mail delivery, without having to rely upon a chain of
> intermediaries and upon the remote end, and without having to inject further
> messages into the system that aren't necessarily going to be delivered
> reliably themselves, gives a benefit to non-UBM senders.  Remember them ?

If you think that eliminating bounce messages was such a useful goal,
which I doubt it is, it could be done though an ESMTP extension. No
new mail protocols are required.

> The whole trust model of IM2000 is that recipients know that message stores 
> work for the senders, and so expect some message stores to be in collusion 
> with malicious senders.  The design accounts for this in a lot of places 
> (Read the section on notification processing policy and the case study of 
> reading mail, for starters.) and people are already familiar with the ways 
> of dealing with this problem.

Yes, and if they worked then nobody would get spam today. Since that
is not the case, they clearly do not work. IM2000 gives very little,
if any, advantage over SMTP in trying to determine unwanted message
sources.

> Storage space is one of the several costs that IM2000 addresses, and
> it is far from being a red herring.  I suggest that you listen to
> mail administrators complaining about how much disc space they have
> to devote to their mail queues, for a while.  And if you still don't
> understand, I suggest that you ask a mailbox-hosting ISP why it
> places quotas on its customers' mailboxes.

Ah, yes, of course. Unspecified experts agree with you in private
email. Sorry, you'll have to try harder than that.

> False.  If it is required, the recipient has the same information to work
> with as can be obtained via "TOP 0" in POP3.  Read the case studies and the
> design principles.  The advantage of IM2000 is that refusal of unwanted 
> mail can _also_ occur, under the direct control of individual recipients, 
> _without even that much_ information having been transferred.

With the variant of IM2000 you propose, absolutely nothing is gained
over SMTP/POP3. You can reject at the message notification point -
exactly the same as, er, the RCPT point in SMTP. You can reject after
retrieving further information from the message store - exactly the
same as, er, TOP in POP3. You can reject after receiving the entire
message - exactly the same as, either SMTP or POP3.

> Just like the cases with POP3, IMAP, "web mail" systems, and mailboxes
> hosted on Microsoft Exchange.  (Ironically, I experienced a delay of several 
> hours fetching mail from a POP3 server just yesterday.)  If you want red 
> herrings, _that_ is a red herring.

Wrong. Such mail servers are *local*, therefore more likely to be
available and more likely to be responsive to complaints. IM2000
message stores are remote, therefore more likely to be unavailable
and more likely to ignore complaints.

> False.  The "connection refused" or "unable to find a server to connect to" 
> response would be immediate, just as it is when one tries to point a web 
> browser at <URL:http://unequivocal.co.uk./>.

Wrong. "Connection refused" is only generated if packets are able to
get all the way to the remote server, the server is still up, and it
sends a RST (or if a firewall in-between sends a RST). Otherwise the
connection must time out.

> JR> Finally, sender authentication. This is the problem that things 
> JR> like SPF try to address. 
> 
> And it's another red herring.  Anonymity is an unavoidable fact of life,
> and it isn't the problem.  Addressing anonymity is addressing the
> wrong problem.

Who said anything about anonymity? Sender authentication is about
ensuring that the sender identity that claims to have sent the message
is genuinely the sender identity that sent it. It has nothing to do
with tying that sender identity to a human being.

> JR> I think that sender authentication is the area that is most promising 
> JR> and should receive the most investigation.
> 
> Then you are addressing the wrong problem.

I think it is you that is addressing the wrong problem. You don't seem
to have any argument as to why sender authentication is not a good and
benefical idea.

> JR> In summary, I think IM2000 makes it easier for spammers to send their
> JR> spam messages, makes it more difficult for recipients to sort out the
> JR> spam from their real correspondence, and diverts attention away from
> JR> more promising approaches to the problem. 
> 
> * True, but artificially increasing the cost of the Internet mail system 
>   is not the goal.  
> * False, and based upon not reading the details.
> * False, and based upon another erroneous idea of what the goal is.

All three of your responses are mistaken.

> is untrue.  If you had, you would have seen the eight URLs that I've 
> given in this discussion already (which has now risen to nine).

I have seen your URLs. These are the vague references to "read the web
site" that I was referring to. Your site does not adequately address
any of the points I have made, otherwise I wouldn't have made them.
There is no point in referring me to things I have already read.

Cheers


Jon