Re: [Asrg] Precedence headers and spam

Vernon Schryver <vjs@calcite.rhyolite.com> Wed, 07 May 2003 14:12 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02124 for <asrg-archive@odin.ietf.org>; Wed, 7 May 2003 10:12:03 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47EL3r20120 for asrg-archive@odin.ietf.org; Wed, 7 May 2003 10:21:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47EL3820117 for <asrg-web-archive@optimus.ietf.org>; Wed, 7 May 2003 10:21:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02053; Wed, 7 May 2003 10:11:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DPft-0001VG-00; Wed, 07 May 2003 10:13:37 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DPft-0001VD-00; Wed, 07 May 2003 10:13:37 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47EIT819790; Wed, 7 May 2003 10:18:29 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47EAI819495 for <asrg@optimus.ietf.org>; Wed, 7 May 2003 10:10:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00982 for <Asrg@ietf.org>; Wed, 7 May 2003 10:00:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DPVU-0001Qo-00 for Asrg@ietf.org; Wed, 07 May 2003 10:02:52 -0400
Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx with esmtp (Exim 4.12) id 19DPVT-0001Ql-00 for Asrg@ietf.org; Wed, 07 May 2003 10:02:51 -0400
Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h47E3grM022488 for Asrg@ietf.org env-from <vjs>; Wed, 7 May 2003 08:03:42 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305071403.h47E3grM022488@calcite.rhyolite.com>
To: Asrg@ietf.org
Subject: Re: [Asrg] Precedence headers and spam
References: <5.2.0.9.2.20030507003217.00b9d538@solidmatrix.com>
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Wed, 07 May 2003 08:03:42 -0600

> From: Yakov Shafranovich <research@solidmatrix.com>


> ...
> as part of an overall solution. If we utilize some form of a RMX/rDNS 
> system, there is still an issue of dealing with the email arriving from 

> ...
> either here or elsewhere on the Net: assigning priority to each message. 
> Messages with different priority levels can be routed accordingly, possible 
> spam can be delayed by a significant number of hours or days during which 
> the spammer's website and email accounts will be probably terminated by 
> their ISP. Legitimate email will still get through, but the inherent 
> "slowness" will force the senders to complain to their ISP to switch over 
> to a RMX or rDNS system.
>
> There are already two headers mentioned in RFC 2076, section 3.9: 
> "Priority:" and "Precedence:" According to RFC 2076 these headers "can 
> ...

I don't understand the idea  It can't be that spam either would or
would not have a Priority or Precedence header as it comes from the
spammer, since spammers would immediately add or not the required
header.  Do you mean that a receiving MTA would add or adjust a header
based on RMX or reverse DNS checking, and then delay or expedite the
message based the value in the header?  Problems I see with that idea are:

  - There's no need for the receiving MTA to add headers.  It could
   must segregate incoming messages, such as into sendmail queue
   directories.  You could delay the processing of some queues.

  - There will be at least as many complaints from local users about
   the delays than from remote users to the remote users' ISPs.  

  - What do you do with spam after it has been delayed, deliver it?
   Or is the idea only to delay and penalize any and all mail with
   RMX/rDNS support by sending MTAs to speed up the transition to
   common support for RMX/rDNS?

  - If you accept the mail and then delay it, it doesn't matter whether
   the spammers accounts have been terminated as far as spam victim is
   concerned.  It's also a stretch to say that the spammer's accounts
   would be terminated within hours or even days.  Many spammers have
   what they call "bulllet proof bandwidth."  Then there are the senders
   of unsolicited bulk advertising including Topica, Roving Software,
   RealNetworks, American Express, and most DMA members (according to
   the DMA if not most DMA members themselves).  There is no prospect
   of the accounts of those organizations being terminated.


Vernon Schryver    vjs@rhyolite.com
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg