Subject: spam

From: "Bill Cunningham" <[email-masked]>
Date: Thu, 29 May 2003 13:18:58 -0400

Personally I think the best idea I've seen yet is the idea of a prefix, such
as ADV in the subject line. The real problem I agree is with sorting through
unsolicited mail for what you really want. It maybe possible to put
something like ADV in a protocol header. Or maybe that is too extreme.

    Bill

---

From: "Fritz F. Saad" <[email-masked]>
Date: Thu, 29 May 2003 12:08:27 -0600

I can only echo Bill's comment on that regards, and I don't find that too
extreme.

Cheers,
Fritz.

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 29 May 2003 14:08:27 -0500

on 5/29/2003 12:18 PM Bill Cunningham wrote:
> Personally I think the best idea I've seen yet is the idea of a prefix,
>  such as ADV in the subject line.

Using the current transfer and message-format models, that requires
post-transfer processing. At a minimum, you would be legitimizing
artificially increased bandwdith and processing demands (assuming that
everybody complied with the law).

> It maybe possible to put something like ADV in a protocol header. Or
> maybe that is too extreme.

A special header would be feasible if the transfer headers and message
headers were separate, since you could reject the message before the
transfer. The same results would also be possible with ESMTP using
something like an ;ADV extension to the MAIL FROM command. Both of those
require wholesale upgrades to have any impact, so in the meantime you'd
still have to rely on post-transfer processing.

There is another significant problem with using an ADV tag with all
commercial mail, which is that it doesn't adequately distinguish between
spam and legitimate commercial mail. Would upgrade notification messages
for stuff like software need to be marked? Would domain renewal notices
from your registrar need to be marked? Would you need to explicitly opt-in
to get those messages without them being marked?

Seems to me we should be defining laws that put the onus on the spammers
rather than on the recipients and legitimate business communications.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/