Subject: [Asrg] Precedence headers and spam

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 07 May 2003 00:32:59 -0400

There is no one overall solution that will magically solve all of our spam 
problems. We must seek a combination of several solutions which can 
significantly reduce the overall volume of spam. Unfortunately, unlike what 
most of us wish spammers are not going away so fast. Neither will any 
servers on the Internet magically start doing SMTP authentication - changes 
can take a lot of time. We need to seek a combination of various changes to 
protocols, policy suggestions and other solutions in order to gradually 
reduce the problem.

In that same vein, I would like to make a small suggestion which can help 
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 
non-RMX/non-rDNS sites especially during the transition process. 
Blacklisting or white listing is not a valid option since that would block 
legitimate mail. I would like to suggest something that I remember seeing 
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 
influence general usage transmission speed and delivery". However, 
according to the same RFC the "Priority" header is "not for general usage" 
and the "Precedence" header is "non-standard, controversial, discouraged". 
Perhaps as part of an overall change in policy and protocols towards a 
spam-free environment we should formalize one of these two headers or 
define a new header, as part of the SMTP protocol and ALSO define format 
procedures as to how the difference "priority" or "precedence" levels 
should be dealt with by MTAs. Sendmail, which is the most popular MTA in 
use already deals with the "precedence" header as can been seen in the 
"Installation and Operation Guide for Sendmail 8.12", section #2.9.3 
(http://www.sendmail.org/~ca/email/doc8.12/op-sh-2.html#sh-2.9.3):

"Precedence

The Precedence: header can be used as a crude control of message priority. 
It tweaks the sort order in the queue and can be configured to change the 
message timeout values. The precedence of a message also controls how 
delivery status notifications (DSNs) are processed for that message. "

I am sure that if this header is formalized or a new header is defined, AND 
formal guidelines are established for routing such mail, SendMail and other 
MTAs can be prevailed upon to support it. I am not suggesting an overall 
solution, just adding another piece of the puzzle.

I would like to hear any comments on this,
Yakov

---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <[email-masked]>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------  

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

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 7 May 2003 08:03:42 -0600 (MDT)

> From: Yakov Shafranovich <[email-masked]>

> ...

> ...
> ...

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    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg