Subject: RE: [Asrg] A New Plan for No Spam / Velocity Indicator

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 26 Apr 2003 07:43:35 -0700

>   The spam problem is solely one with the SMTP protocool. 

Not quite, it also comes with SMS messages, and telephone calls
and... well pretty much evey protocol where the conversation is
initiated by someone other than the recipient.

> No one
> claims that IMAP or POP have a major (or even minor) role in
> originating spam. 

Apart from Vernon when it suits the point he is trying to make.

The problem of spam email is as you point out unique to the hop
over the general internet. IMAP and POP are only ever used with
specific trusted sites that the user has selected.

> >  Besides, the "pulling" of NNTP had nothing to do with controlling
> > netnews spam.
> 
>   It gives the "pulling" server more control over the traffic it
> accepts.  Too much spam in alt.sex?  Stop asking for it.  That can be
> done with NNTP, IMAP, and POP, as they permit the "pull" host to not
> ask for traffic, and that traffic stops.  It can't be done with SMTP.

NNTP has problems but they are not intrinsic to the concept or even
the protocol, take a look at slashdot, almost no spam ever appears
there (unless you count the editors plugging of personal agendas :-).

>   As I said in the first week this list started, a large part of the
> spam problem is the design of the SMTP protocol.  It is *designed* to
> permit anonymous originators, lying about message authors, redirection
> of traffic to anyone, and traffic amplification.  No other network
> protocol has all of these "features".  As a result, no other protocol
> has the continuing problem that SMTP has.

Genuinely anonymous communication is not that useful, what people really
want is some form of pseudonymity. They want to be able to carry on
conversations behind an assumed identity that cannot be connected to 
the offline world.

People could always post anonymously on usenet, but Wizvax and pinet
were interesting because you could get confidential replies.

		Phill
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: J C Lawrence <[email-masked]>
Date: Sat, 26 Apr 2003 12:29:39 -0700

On Sat, 26 Apr 2003 07:43:35 -0700 

> initiated by someone other than the recipient.

I'm told that IM spam via Yahoo/MSN/etc al is becoming common.  I've not
seen it under Jabber.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
[email-masked]               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 26 Apr 2003 17:41:51 -0400

> initiated by someone other than the recipient.

  Yes, but SMTP allows you to do something that telephone calls and
SMS don't: send the same traffic to multiple users at the remote site.
I can't call your house, and force everyone in your house to listen to
the message.  I can only leave one copy of the message, and it only
gets duplicated if you choose to duplicate it.

  This problem becomes geometrically worse with open relays/proxies.
I don't know of any open telephone answering machine I can call which
will automatically dial any number of destinations I choose, and
deliver my message.

  Alan DeKok.

---

From: J C Lawrence <[email-masked]>
Date: Sat, 26 Apr 2003 18:06:27 -0700

On Sat, 26 Apr 2003 17:41:51 -0400 
Alan DeKok <[email-masked]> wrote:

> Yes, but SMTP allows you to do something that telephone calls and SMS
> don't: send the same traffic to multiple users at the remote site.  I
> can't call your house, and force everyone in your house to listen to

My native suspicion is that RCPT TO bundling is going to have to go.
Certainly for my own systems I'm more or less compleatly disabled it via
outbound rewriting via TMDA which unrolls any RCPT TO bundles (only hold
out is Mailman, and that only until I upgrade to 2.1 and VERP).

---

From: "Jon Kyme" <[email-masked]>
Date: Sun, 27 Apr 2003 17:32:39 +0100

> out is Mailman, and that only until I upgrade to 2.1 and VERP).

That's a shame, particularly given that the RFCs require that I must accept
100 rcpts.

---

From: J C Lawrence <[email-masked]>
Date: Sun, 27 Apr 2003 10:02:04 -0700

On Sun, 27 Apr 2003 17:32:39 +0100 
Jon Kyme <[email-masked]> wrote:

>> Certainly for my own systems I'm more or less compleatly disabled it
>> via outbound rewriting via TMDA which unrolls any RCPT TO bundles
>> (only hold out is Mailman, and that only until I upgrade to 2.1 and
>> VERP).

> That's a shame, particularly given that the RFCs require that I must
> accept 100 rcpts.

Oh, I don't think it will be removed from the SMTP spec, but that
implementation of consent mechanisms will have the side effect of
causing single RCPT TO per message.

---

From: "Mark Delany" <[email-masked]>
Date: 27 Apr 2003 21:49:30 +0000

> causing single RCPT TO per message.

Why? Couldn't consent information be sent as part of the RCPT TO:
using the <rcpt-parameters> as defined in RFC2821?

MAIL FROM: <[email-masked]>
RCPT TO: <[email-masked]> permission-given=blah1
RCPT TO: <[email-masked]> permission-given=blah blah

Regards.

---

From: J C Lawrence <[email-masked]>
Date: Sun, 27 Apr 2003 16:11:21 -0700

On 27 Apr 2003 21:49:30 +0000 
Mark Delany <[email-masked]> wrote:
>> On Sun, 27 Apr 2003 17:32:39 +0100 Jon Kyme <[email-masked]>
>> wrote:

>>>> My native suspicion is that RCPT TO bundling is going to have to
>>>> go.  Certainly for my own systems I'm more or less compleatly
>>>> disabled it via outbound rewriting via TMDA which unrolls any RCPT
>>>> TO bundles (only hold out is Mailman, and that only until I upgrade
>>>> to 2.1 and VERP).

> using the <rcpt-parameters> as defined in RFC2821?

Because the consent information needs to be encoded in a fashion that is
a) supported by currently deployed MTAs, and b) will be transparently
and auditably communicated to MUAs.  There are loads of approaches, like
RCPT TO encoding that could be used if we were also able to
significantly change deployed software both at the core and the edge.  I
don't see that happening.

---

From: "Jon Kyme" <[email-masked]>
Date: Mon, 28 Apr 2003 09:54:58 +0100

> RCPT TO: <[email-masked]> permission-given=blah blah

I guess so. If someone takes the trouble of defining this extension.

---

From: Kee Hinckley <[email-masked]>
Date: Mon, 28 Apr 2003 16:57:32 -0400

>I'm told that IM spam via Yahoo/MSN/etc al is becoming common.  I've not

I don't think I've seen anyone propose doing what AOL does with AIM to email.

Admittedly, it only works because AOL controls all the servers, but 
that hasn't stopped any other proposals :-).

If someone sends you an unwanted instant message, you simply dis 
them.  (Okay, AOL doesn't call it that, but I can never remember 
their word for it.)  The sender's messages are now delivered slowly 
for some period of time.  If more than a few people do the same, they 
can't send at all for a while.  Simple, understandable, efficient, 
and effective.

It's not going to work for email though.  In fact its weak point is 
that AOL uses email as the authentication mechanism.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: J C Lawrence <[email-masked]>
Date: Mon, 28 Apr 2003 18:38:53 -0700

On Mon, 28 Apr 2003 16:57:32 -0400 
Kee Hinckley <[email-masked]> wrote:
>> On Sat, 26 Apr 2003 07:43:35 -0700 Phillip Hallam-Baker
>> <Hallam-Baker> wrote:

> that hasn't stopped any other proposals :-).

AOL has vigorously defended this service monopoly.  There are multiple
Open Source implementations of the AIM protocol server, but should any
particular site running one becomre more than trivially popular, AOL IP
blocks the server from their AIM network.

This isn't, or shouldn't be surprising, but is worth noting.