A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension
draft-malamud-no-soliciting-07

[Note]: 'This document was revised between version -06 and -07 to remove the registry of keywords. Instead, DNS is leveraged for keyword ownership.' added by Harald Alvestrand

I talked with Carl today at lunch about a number of issues which I'd raised in my discuss comments.  At this point, he'll add the information related to the klyne header registry, update the text to describe the process by which a binary up/down was considered and rejected.  He'll also remove the example in 4.3.1 that describes the behavior of an intermediate MTA using this header, with the intention it may be a later document that can more fully specify how the opes-like considerations here apply.

The other main issue, the registry, turns out to have been a misunderstanding in my reading the text.  He intends to set up a registry which is *not* associated with the IETF;  the existing text
(which specifies RFC publication) was a cut-and-paste, where his
real intention is to keep the IETF out of this by having a registry
whose policies for this come from ICANN, rather than the IETF.
I've suggested he work with Thomas Narten to find language that
meets his needs without confusing it with a standard IETF/IANA
protocol registry.

[Ballot discuss]
Section 4.4 notes that there is no header registry at IANA, but we just approved
Graham Klyne's header registry document, so this is no longer true.

Section 4.3.1 gives guidance on using keyword specification, and contains the
following text:


  This facility can be used to insert a "score" or category tag by an
  intermediate MTA.  For example, a solicitation class keyword "WMA:*"
  might be used as follows:

    Received: by foo-mta.example.com with
        ESMTP (WMA:SBRule:Haven_Domain,WMA:SBScore:10) ; Sat, 9 Aug 2003
        16:54:42 -0700 (PDT)

This seems pretty advanced for the state of play of this set of tools, and I
believe the role of an intermediate MTA inserting such a category tag
is underspecified at this time.  I would strongly suggest removing it and
specifying it in a separate document, especially since the heuristics applied
at an intermediate MTA to add this data have security considerations
that are not covered in Section 3.0

On a more general note, I wonder whether the utility of this mechanism is
actually increased by the inclusion of the solicitation classes.  I note that
the document's physical solicitation parallels (to "no soliciting" signs and
registrations) are all fairly general and do not contain similar classes.  As
far as I am aware, there are no physical signs saying "religious disputation
welcome, but don't try to sell me household products", which is along
the lines of what this will do.  Thomas Narten has expressed concerns
about the IANA burden related to the population of this registry, and I share
them; who would take the job of IANA designated expert here?  Even under the
best of circumstances, it seems likely that the registrations will have to be
very large in number to handle different community norms.  Having registrations
like ADV:ADLT-Sweden and ADV:ADLT-Iraq and ADV:ADLT-Alabama will clog things
up pretty quickly.  Similar situations will arise in different contexts (Is ephedra
a therapeutic drug, a banned substance, an herbal extract?  What about marijuana?)

If the 90/10 rule on this means we can have a header that says "Solicitation: yes" and
a No-soliciting keyword and handle the vast majority of the need for this, I think
it should be considered.

[Ballot discuss]
Section 4.4 notes that there is not header registry at IANA, but we just approved
Graham Klyne's header registry document, so this is no longer true.

Section 4.3.1 gives guidance on using keyword specification, and contains the
following text:


  This facility can be used to insert a "score" or category tag by an
  intermediate MTA.  For example, a solicitation class keyword "WMA:*"
  might be used as follows:

    Received: by foo-mta.example.com with
        ESMTP (WMA:SBRule:Haven_Domain,WMA:SBScore:10) ; Sat, 9 Aug 2003
        16:54:42 -0700 (PDT)

This seems pretty advanced for the state of play of this set of tools, and I
believe the role of an intermediate MTA inserting such a category tag
is underspecified at this time.  I would strongly suggest removing it and
specifying it in a separate document, especially since the heuristics applied
at an intermediate MTA to add this data have security considerations
that are not covered in Section 3.0

On a more general note, I wonder whether the utility of this mechanism is
actually increased by the inclusion of the solicitation classes.  I note that
the document's physical solicitation parallels (to "no soliciting" signs and
registrations) are all fairly general and do not contain similar classes.  As
far as I am aware, there are no physical signs saying "religious disputation
welcome, but don't try to sell me household products", which is along
the lines of what this will do.  Thomas Narten has expressed concerns
about the IANA burden related to the population of this registry, and I share
them; who would take the job of IANA designated expert here?  Even under the
best of circumstances, it seems likely that the registrations will have to be
very large in number to handle different community norms.  Having registrations
like ADV:ADLT-Sweden and ADV:ADLT-Iraq and ADV:ADLT-Alabama will clog things
up pretty quickly.  Similar situations will arise in different contexts (Is ephedra
a therapeutic drug, a banned substance, an herbal extract?  What about marijuana?)

If the 90/10 rule on this means we can have a header that says "Solicitation: yes" and
a No-soliciting keyword and handle the vast majority of the need for this, I think
it should be considered.

[Note]: 'Although last call for the doc doesn''t end until
26-Feb-2004, I''d really like to get feedback on this
time-sensitive specification from the IESG rather than
wait until after Korea. There''s also the issue of
context being lost in the handoff to a new AD...' added by Ned Freed