draft of Simple Junk Mail Declaration Protocol

I have written a description of a simple protocol.  The front matter,
back matter, abstract are missing.  It is available at

http://zarquon.advenge.com/RFCwiki/view?doc=AI

as well as appearing attached to this message.

-- 
[email protected]
"There's a fine line between participation and mockery" -- Scott Adams
Simple Junk Mail Declaration Protocol
=====================================

Front Matter

1 

introduction

2 

definition of "Shared Designation Engine"

3 

downstream communication

3.1 

Is-Junk

3.2 

Is-Not-Junk

4 

upstream communication

4.1 

If-Junk

4.2 

If-Not-Junk

5 

Compliance

5.1 

MTA Compliance

5.1.1 

headers appearing in outgoing messages

5.1.2 

lifetime of keyed URLs

5.1.3 

accepting authorized advice

5.1.4 

rejecting non-authorized advice

5.1.4.1 

by mailto

5.1.4.2 

by hypertext

5.1.5 

renaming pre-existing headers in incoming messages

5.1.5.1 

exception to renaming/deleting

5.1.5.1.1 

exception to exception

5.1.6 

support for legacy SDEs

5.1.6.1 

legacy downstream communication

5.1.6.2 

legacy upstream communication

5.2 

MUA Compliance

5.2.1 

compiance of current installed software

6 

Difficult Scenarios

6.1 

Foreign SJMDP

6.2 

multiple designation engines

7 

Back Matter

------------------------------------------------------------------------

.Front Matter

standard internet draft front matter goes here

1.introduction

Four RFC2822 headers are proposed, to appear in mutually exclusive pairs,
concerning designation of messages as junk or not-junk and
communicating methods of tuning the designation engines.

2.definition of "Shared Designation Engine"

A "Designation Engine" is a component of a messaging system that is
designates if a given message is or is not junk.  The Shared Designation
Engine described in this document is used by multiple individual natural
persons who subscribe to it to advise their e-mail software to classify
certain messages as junk.

3. downstream communication

Communication of a junk status designation from messaging system to user
software is provided with either an Is-Junk or an Is-Not-Junk header.

Both headers are of the form

     HEADERNAME: EXPLANATION

where HEADERNAME is either Is-Junk or Is-Not-Junk and
EXPLANATION is either an extended explanation of the process used
to arrive at the designation or a hypertext URL which, when accessed,
will provide such an explanation.

When the explanation is an URL, it may expire. (see section 5.1.2)

3.1. Is-Junk

Is-Junk:  EXPLANATION

The appearance of an Is-Junk header should be sufficient cause for a MUA
application to file a message as Junk.

SJMDP-compliant messaging systems MUST include this header when appropriate.

3.2. Is-Not-Junk

Is-Not-Junk:  EXPLANATION

The appearance of an Is-Not-Junk header should be sufficient cause for a
MUA application to treat a message as Not Junk.

This header is optional.

4. upstream communication

Communication of a junk status designation change request from user to
messaging system software is accomplished via a method described in an
If-Junk or If-Not-Junk header.

Both headers are of the form

     HEADERNAME: METHOD

where HEADERNAME is either If-Junk or If-Not-Junk and
METHOD is either an e-mail address prefixed with "mailto:" or a
hypertext URL which, when accessed, will communicate the status
designation change request.

The reclassification instruction may be of the form
"mailto: [email protected]"
in which case the message it to be delivered unmodified via SMTP to the
provided e-mail address, or the reclassification instruction may be a
hypertext URL containing enough data encoded in it to be an effective
reclassification instruction. 

When the reclassification instruction mechanism is an URL, it may
expire. (see section 5.1.2)

4.1. If-Junk

The If-Junk header is associated with the Is-Not-Junk header, and
provides a mechanism to request classification of messages such as the
one in which it appears as Junk in the future.

The If-Junk header SHOULD NOT appear in messages that are, according to
local policy, never to be classified as junk.

The If-Junk header MUST NOT appear in messages that are already
classified as junk.

4.2. If-Not-Junk

The If-Not-Junk header is associated with the Is-Junk header, and
provides a mechanism for the MUA to request classification messages such
as the one in which it appears as Not-Junk in the future.

The If-Not-Junk header MUST NOT appear in messages that are not
classified as junk.

5.Compliance

New MUA and MTA/MDA software written to comply with this standard should
interoperate, in that the JUNK/NOT-JUNK button will communicate tuning
requests to the correct shared designation engine in a way it can
understand, with a minimum of configuration.

5.1. MTA Compliance

SJMDP-compliant software upstream of the end-user inserts SJMDP headers
into messages passing through, or delivered by, it.

SJMDP compliant messaging software MUST rename or delete pre-existing
SJMDP headers.

The engine tuning instructions provided in any particular message
MUST match the engine used to provide the designation. (see 6.2)

5.1.1. headers appearing in outgoing messages

All SJMDP headers SHOULD be deleted from outgoing messages. Forwarding
is not "outgoing" but rather is a form of delivery. (see section 6.1.)

5.1.2.lifetime of keyed URLs

When the URL forms of explanation and method are used, the URL may
encode the full explanation, or the full modifications that would be
made to the  SDE, in a form that will simply be expanded, or the URL may
include a key into a database, or a combination of these approaches.

When a key system is used, URLs should be valid for at least a week.

5.1.3.accepting authorized advice

SDEs using the "mailto" upstream communication method MUST accept tuning
instructions as MIME attachments as well as resent messages

5.1.4.rejecting non-authorized advice

SJMDP-compliant shared designation engines SHOULD NOT accept tuning
instructions except from the mailbox owners who share the given
designation engine.

5.1.4.1. by mailto

SMTP AUTH or network address checks should be adequate, expiring
capability keys can be appended to tuning reporting addresses as well.

5.1.4.2. by hypertext

Embedding expiring capability keys into secure hypertext https: METHODs
should be more than adequate.

5.1.5. renaming pre-existing headers in incoming messages

SJMP compliant messaging software MAY rename SJMP headers instead of
deleting them. When renaming is performed,  vendors SHOULD follow the
conventions

     X-VENDORSTRING-Renamed-Is-(Not-)-Junk: EXPLANATION

and

     X-VENDORSTRING-Renamed-If-(Not-)-Junk: METHOD

VENDORSTRING SHOULD include information identifying the SJMDP software
as well as the identity of the installation, for instance

     X-Advenge-DE-3-14-Folderol-Example-Net-Renamed-Is-Junk:
       http://listserv.example.org:9999/poiuytrew

would indicate that the Advenge Designation Engine version 3.14 running
on folderol.example.net renamed an Is-Junk header with a keyed
explanation URL.

When a renaming SJMDP engine encounters its own VENDORSTRING while
rewriting SJMDP headers, it SHOULD double it.

5.1.5.1. exception to renaming/deleting

When the owner of the mailbox to which delivery is being made has
specified the source of the message as trusted for purposes of SJMDP
(section 6.1),  SJMDP classification and designation MUST NOT be
performed.

5.1.5.1.1. exception to exception

SJMDP information MAY be added to a message arriving from a trusted
source for a mailbox with an exception when no SJMDP headers are in the
message already.

5.1.6.support for legacy SDEs

Compliant MUA software SHOULD offer configuration options to support
non-compliant shared designation engines.

5.1.6.1. legacy downstream communication

Compliant MUA software SHOULD offer configuration options to supoprt
classificiation of incoming messages as junk/not-junk based on
appearance of and information contained in arbitrary specifiable headers.

5.1.6.2. legacy upstream communication

Compliant MUA software SHOULD allow the user to set e-mail addresses to
which Junk and Non-Junk should be forwarded on user identification of
misclassified junk and non-junk.

5.2. MUA Compliance

A compliant mail user agent software 

  * MUST offer a way to configure a sorting or delivery rule based on
appearance or non-appearance of the SJMDP Is* headers

  * MUST correctly implement the designation engine tuning methods
described

  * SHOULD offer an easy way to view expansions of URL-style
explanations and methoda

5.2.1. compiance of current installed software

MUA software MAY satisfy compliance criteria by allowing views of full
e-mail headers and/or message source code

All MTA software that offers message filing based on appearance
of arbitrary headers is therefore technically compliant, when associated
with web browsers and SMTP-capable telnet software, or with a SDE that
accepts tuning requests as attachments (section 5.1.3)

6.Difficult Scenarios

6.1.Foreign SJMDP

A designation engine SHOULD offer a per-mailbox configuration option in
which a mailbox can be designated as not participating in SJMDP, to
support users who are having their messages forwarded from a trusted
non-local SJMDP service.  Opting out of SJMDP header rewriting
SHOULD be configurable based on SMTP peer network addresses or
HELO/EHLO identifiers or some other SMTP peer identification criteria.

6.2. multiple designation engines

Some messaging evironments have different factions of users with
differing is-junk/is-not-junk criteria. SJMDP does not allow for
multiple results on different spectra to be provided via SJMDP.

Vendors of compliant designation engines MAY provide information about
designations other than the one to which a user is subscribed.

Vendors who choose to do so SHOULD follow the convention

     X-VENDORSTRING-Is-(Not-)-Junk-Enginename: EXPLANATION

to facilitate users selecting an active engine for their individual
accounts from among the several available named designation engines.

Vendors of SJMDP-compliant MUA software MAY recognize this convention
and incorporate it into the user configuration interface, perhaps by
preloading such headers that appear in a message into a message filing
rule creation or editing dialogue menu.

Designation engine software SHOULD NOT include tuning methods for
engines other than the one to which a user is subscribed.

7.Back Matter

author info, bibliography

David Nicol
TipJar LLC
Post Office Box 45163
Kansas City, Missouri 64171 USA

------------------------------------------------------------------------

The RFCwiki tool is cheerfully maintained by David L. Nicoltipjar tip jarYour direct support is appreciated
post office box 45163
Kansas City, Missouri 64171-8163
United States of America