Subject: SUBMITTER extra information

From: Pavel Zavyalov <[email-masked]>
Date: Sun, 25 Jul 2004 17:12:38 +0400

Some (re-) submitting system may want to notify receiving system some extra
information about precedence / priority of messages.

Examples
* Forwarders may run spam filters and know submitting message is suspicious
* Postcards/'Send-link-to-friends services may know submitting user is
anonymous or may be forged
* Something else 

Extension like
MAIL FROM:<[email-masked]> SUBMITTER:<[email-masked]>
EXTRA="junk"
will be (imho) useful in this case
List of available must be reserved (may be JUNK, LIST, SUSPICIOUS,
ANONYMOUS, FIRST-CLASS), usage of extra info may be unspecified, receiving
server can interpret extra info by his own rules and/or reputation services.

Thank you,
Pavel
 
--
Pavel A. Zavyalov
Yandex Mail project manager
Yandex
http://mail.yandex.ru
http://yandex.ru

---

From: "Douglas Otis" <[email-masked]>
Date: Sun, 25 Jul 2004 09:45:38 -0700 (PDT)

> server can interpret extra info by his own rules and/or reputation

A merger of BATV/SPF to protect the RFC 2821 MAIL FROM will not expose an
additional mailbox address as will SUBMITTER.  This is important as
SENDER-ID et al will not reduce the amount of spam.  In addition, there
will be no means to accredit abuse with SUBMITTER.  Unlike a merger of
BATV and SPF, much less of the mail system is damaged as with SUBMITTER. 
In general, SUBMITTER is unfriendly.

-Doug

---

From: Meng Weng Wong <[email-masked]>
Date: Sun, 25 Jul 2004 23:23:57 -0400

On Sun, Jul 25, 2004 at 05:12:38PM +0400, Pavel Zavyalov wrote:
| 
| Extension like
| MAIL FROM:<[email-masked]> SUBMITTER:<[email-masked]>
| EXTRA="junk"
| will be (imho) useful in this case
| List of available must be reserved (may be JUNK, LIST, SUSPICIOUS,
| ANONYMOUS, FIRST-CLASS), usage of extra info may be unspecified, receiving
| server can interpret extra info by his own rules and/or reputation services.

I agree that a relatively freeform "extra" field type is
desirable; with such a field type, it will be easier to
experiment with future extensions before standardization.

To ensure that this field doesn't become the "TXT" of ESMTP,
perhaps we should define a namespace under which all
extensions not recognized should be ignored.  That would
allow "de facto" extensions to quickly achieve critical mass
through Darwinian processes without bureaucratic overhead.

  MAIL FROM:<[email-masked]> X-WHATEVER=...

If an ESMTP receiver has "X-" support, it could advertise
that fact in the EHLO response.  The WHATEVER namespace
could be the subject of an IANA registry.

Examples:

  MAIL FROM:<[email-masked]> X-foo=foo

  MAIL FROM:<[email-masked]> X-bar=bar X-baz=baz

We're getting kind of off topic, maybe this conversation
could move into the WG responsible for the next ESMTP RFC.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 26 Jul 2004 01:08:32 -0700

Meng,

MWW> I agree that a relatively freeform "extra" field type is
MWW> desirable; with such a field type, it will be easier to
MWW> experiment with future extensions before standardization.

The history of x- fields from RFC733/RFC822 shows the flaw in that
approach: If the field is of any use, then it gets popular.

It is extremely rare that folks then migrate from the original header to
a header with a different name.

MWW> To ensure that this field doesn't become the "TXT" of ESMTP,
MWW> perhaps we should define a namespace under which all
MWW> extensions not recognized should be ignored.

In other words, you want to standardize the experimental field, by
creating a new administrative effort.

It would be far simpler to just use the existing administrative effort.
This has the benefit of requiring no future transition for the installed
base.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>