Subject: [Asrg] re: RFC 2076 and spam

From: Jacob Palme <[email-masked]>
Date: Mon, 12 May 2003 18:14:38 +0200

The proper recipient to send this query to would be
eitherone of the IETF mailing lists for experts on
e-maillike for example IETF-822 Mailing List
<[email-masked]>, which is the most active present
mailing list on e-mail standards, or a selection of the
major experts in this area. I have added such a selection
as recipients of this e-mail, to save a step.

Here is what I believe these experts are going to say to you:

The "Precedence" and "Priority" e-mail headers are not
recommended in RFC 2076, because they have been used, and
are still being used, by different e-mail systems in
different ways. Thus, if you choose to use any of these
headers, your usage may conflict with existing usage by
some existing mail systems.

Because of this, these experts will recommend that you
handle this by a new header field not yet used for any
other purpose.

Some of the more dogmatic experts may say that you should
not use header fields at all, but instead some kind of SMTP
information. I would not agree, myself, with that more
fundamentalistic view.

My understanding is that there are already a number of
spam-control e-mail headers, so one task of your group
might be to specify a standard for such headers.

At 00:39 -0400 03-05-07, Yakov Shafranovich wrote:
>Dear Prof. Palme,
>
>I am part of the IRTF working group on spam 
>(http://www.irtf.org/charters/asrg.html). I came across 
>your comments on the "Precedence" and "Priority" headers 
>in RFC 2076. I would like to share a copy of a proposal 
>with you regarding using those fields to fight spam and 
>wanted to know your thoughts on the matter.
>
>Sincerely,
>Yakov Shafranovich
>
>>Date: Wed, 07 May 2003 00:32:08 -0400
>>To: [email-masked]
>>From: Yakov Shafranovich <[email-masked]>
>>Subject: Precedence of spam
>>
>>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 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)
>>---------------------------------------------------------------------------------------------------

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 13 May 2003 09:40:08 -0400

> >>reduce the overall volume of spam.

I'm not so sure that we can't completely re-invent the way that mail is
delivered while also still maintaining compatibility with existing SMTP
servers.  Cutting spam in half means spammers will send twice as much spam.
If we don't invent something that completely and absolutely is not
fool-proof we probably shouldn't do anything at all.  This isn't to say that
someone could not send out undeseriable email solicitations using whatever
we help invent here, but that no one would have to ask "Who really sent this
and where did it come from?"