On Sun, Jul 25, 2004 at 05:12:38PM +0400, Pavel Zavyalov wrote:
|
| Extension like
| MAIL FROM:<user(_at_)somehost(_dot_)dom>
SUBMITTER:<user(_at_)my_spam_markup_forwarder(_dot_)ru>
| 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:<user(_at_)somehost(_dot_)com> 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:<user(_at_)somehost(_dot_)com> X-foo=foo
MAIL FROM:<user(_at_)somehost(_dot_)com> 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.