Subject: Re: Last Call: <draft-melnikov-smtp-priority-07.txt> (Simple MailTransfer Protocol extension for Message Transfer Priorities)to Proposed Standard

From: "t.petch" <[email-masked]>
Date: Thu, 1 Mar 2012 10:45:09 +0100

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 01, 2012 5:43 AM
> - Appendix D: "This appendix and its subsections are informative."  I think
that (a) any appendix is informative, because normative text doesn't belong in
an appendix; and (b) the normative stuff uses RFC2119 language and this doesn't.
Thus, I think this sentence should be removed.  (I know I've lost this argument
before, but I'll make another stand here anyway.)
I hope that you lose again:-)  I am always confused, since I see a substantial
number of normative appendices and so want it clearly spelt out, is it
informative, what happens when the body clashes with the appendices etc etc.

Tom Petch

> -MSK

---

From: Barry Leiba <[email-masked]>
Date: Thu, 1 Mar 2012 15:49:39 -0500

I had expected that we'd deal with my shepherd review before doing the
last call on the document.  Because that didn't happen, I'll re-post
my review here, as public last-call comments.  Maybe that will prevent
people from raising the same things I've already raised.

First, two additional points:

1. As to Murray's comment about explicitly declaring text to be
informative, I'm with Tom on this: I think it's at worst harmless, and
possibly very useful as a clarification, to explicitly say "this
[paragraph, section, whatever] is not normative."  It might be
unnecessary, but where's the harm?

2. I, too, noticed all the lower-case "should" and "may" words.  I
suggest that the best way to handle this is to make the following
change to the RFC 2119 citation text at the beginning of section 2:

NEW
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] when they appear
   in ALL CAPS.  These words also appear in this document in lower case as plain
   English words, absent their normative meanings.

My review, which was already sent to Alexey and Pete:

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

Section 4.1
  1.  A conforming SMTP server SHOULD NOT refuse a MAIL command based
      on the absence of the PRIORITY parameter.

I agree with Pete's MUST NOT -- also because at this point, the server
has no idea whether the message is coming from a non-supporting
server, and whether or not there's an MT-Priority header field in the
message.  This really needs to be MUST NOT.

-----
Section 4.4
  1.  A PRIORITY parameter MUST NOT appear in the MAIL command issued
      when relaying the message.

  2.  The relaying MTA MUST first remove any and all existing MT-
      Priority header fields from the message, and then add its own MT-
      Priority header field with the value determined by the procedure
      in Section 4.2.  One exception to this rule is that a message
      which didn't contain any MT-Priority header field and which
      didn't have the PRIORITY MAIL FROM parameter specified doesn't
      need to be updated to contain the "MT-Priority: 0" header field.
      Syntax of the MT-Priority header field is specified in Section 7.

Because of the exception, I think there's a slight unclear point here
(and I also don't like the passive voice in bullet 1).  Let me re-work
this thus:

NEW
  1.  The relaying MTA MUST NOT use the PRIORITY parameter in the
      MAIL command issued when relaying the message.

  2.  The relaying MTA MUST first remove any and all existing MT-
      Priority header fields from the message.

  3.  If the message had a PRIORITY specified in the MAIL FROM
      parameter *or* there was an MT-Priority header field
      removed in step 2, then the relaying MTA MUST add its own
      MT-Priority header field with the value determined by the
      procedure in Section 4.2.

      The syntax of the MT-Priority header field is specified in
      Section 7.

-----
Section 5.
  A message priority is a decimal integer in the range from -9 to 9
  (inclusive).  SMTP servers compliant with this specification are not
  required to support all 19 distinct priority levels (i.e. to treat
  each priority value as a separate priority), but they MUST implement
  at least the following 6 distinct priority levels: -4, -2, 0, 2, 4,
  9.  I.e. an implementation that only supports the 6 priority levels
  will internally treat all syntactically valid priority values below
  and including -4 as priority -4, priorities -3 and -2 as priority -2,
  priorities -1 and 0 as priority 0, etc., with all priorities starting
  from 5 are treated as priority 9.  An SMTP server MAY support more
  than 6 different priority levels.  Decision about which levels to
  support in addition to the 6 mentioned above is a local matter.

There's a lot of stuff after the "I.e.", much of which can be changed
to just say that a syntatically valid level that isn't supported gets
raised to the next higher supported number.  Say that, and it all
looks clearer and easier.

-----
Editorial:
OLD
  Note: 19 possible priority levels are defined by this specification
  for extensibility, for example if a particular implementation or
  deployment environment needs to provide fine grainer control over
  message transfer priorities, for example a server implementation may
  need to have an extra high priority level to the 6 levels defined
  above.

NEW
  Note: 19 possible priority levels are defined by this specification
  for extensibility. For example, a particular implementation or
  deployment environment might need to provide finer-grained control
  over message transfer priorities.  In such a case, a server
  implementation might need an extra priority level beyond the 6 levels
  defined above.

-----
Editorial:
OLD
Such actions usually need user confirmation.
NEW
Such actions usually require user interaction.

-----
Section 5.1
  As a default policy, emails with higher priority waiting to be sent
  by a client SHOULD NOT initiate transactions for emails with lower
  priorites.  If two or more emails with the same priority are ready to
  be sent at the same time, the MTA should use its regular algorithm
  (the algorithm used in absence of this SMTP extension) for deciding
  how to send them out.

I have no idea what the first sentence means.  For the second
sentence, I would say it like this: "Within a priority level, the MTA
uses its normal ordering for the messages."

-----
Section 5.2
Editorial:
OLD
  An important constraint (usually associated with higher priority
  levels) is, that messages with that priority have to reach its
  destination within a defined period of time.  In some cases, higher
  priorities mean shorter maximum allowed time of delivery.
NEW
  An important constraint (usually associated with higher priority
  levels) is that messages with high priority have some delivery
  time constraints.  In some cases, higher priorities mean a shorter
  maximum time allowed for delivery.

And I would add to the second paragraph, "But note that use of the
DELIVERBY extension alone does not guarantee any priority processing."

-----
Section 6
I would switch sections 6 and 7, to avoid the forward reference in the
current section 6.

-----
Section 8. Example
I'd like to see an example that includes multiple hops, and that
includes transit across an MTA that doesn't support this.  Perhaps a
life-cycle example: MUA -> MSA -> MTA1 -> MTA2 -> MTA3 -> MDA, where
MTA2 does not support the priority extension.  Maybe:
MSA is mail.alertservice.example
MTA1 is outbound.alertservice.example
MTA2 is relay.backbone.example (doesn't support)
MTA3 is mx1.isp.example
MDA is mailbox5.isp.example

The one simple example doesn't convey much that's useful about how the
various bits work, and especially how the parameter tunneling works.
(You'll also need to provide message headers in the DATA section in
order to show that.)  I think it makes for a bulky Examples section,
but I think it's important.

I think I would do this as separate subsections:
8. Example
8.1 Message Submission
8.2 Relay to Internet Edge MTA
8.3 Relay through Internet Backbone
8.4 Relay to ISP's Edge MTA
8.5 Delivery to ISP User's Mailbox

-----
Section 10
I think the SMTP parameters should match the header field, and all be
MT-PRIORITY.  I'm not going to fight about it, though.

-----
Section 12.1
I am concerned that we're somewhat overloading DKIM here, by asking an
MTA to DKIM-sign a message *solely* to protect the value of one
specific header field.  That's a bit of a stretch, and causes some
level of problem in some cases.  Consider the example above, and
suppose that MSA DKIM-signs the message, with no MT-Priority header
field.  Now MTA1 has to add MT-Priority in order to relay to MTA2, and
it DKIM-signs it again... but perhaps only covering the "from" and
"mt-priority" fields.  None of that is a *huge* deal, but it just
strikes me as an odd use of DKIM, which goes beyond the semantics we
put on it.

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

Barry, document shepherd

---

From: SM <[email-masked]>
Date: Thu, 01 Mar 2012 13:36:09 -0800

At 16:42 29-02-2012, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>- 'Simple Mail Transfer Protocol extension for Message Transfer
>    Priorities'
>   <draft-melnikov-smtp-priority-07.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2012-03-28. Exceptionally, comments may be

This draft specifies a SMTP extension.  The IANA Considerations does 
not mention registration in the the SMTP Service Extensions 
registry.  There should also be an indication about the extension 
being valid for the submit port.  The issue of referencing STANAG 
4406 was resolved by the IESG last year (see RFC 6477).

This draft also defines the MT-Priority header field.  It is quite 
unusual for a SMTP extension specification to define a mail header 
field.  If I had an reservations about this draft, it would be on 
architectural grounds.  The draft tries really hard to transfer 
priority information over the Internet and in a foreign 
environment.  Although the draft is well-written and can be 
implemented, I have doubts about whether it will achieve its 
objective.  I unfortunately cannot support the publication of this 
draft as a Proposed Standard.

Regards,
-sm

---

From: Barry Leiba <[email-masked]>
Date: Thu, 1 Mar 2012 16:53:29 -0500

> This draft specifies a SMTP extension.  The IANA Considerations does not
> mention registration in the the SMTP Service Extensions registry.

It certainly does, in the first paragraph:

   This specification requests IANA to add the PRIORITY SMTP extension
   to the "SMTP Service Extensions" registry (in
   http://www.iana.org/assignments/mail-parameters).

> There
> should also be an indication about the extension being valid for the submit
> port.

Section 3:
   7.  The PRIORITY extension is valid for the submission service
       [RFC6409] and LTMP [RFC2033].

(Murray has already commented on the misspelling of "LMTP" here.)

> This draft also defines the MT-Priority header field.  It is quite unusual
> for a SMTP extension specification to define a mail header field.  If I had
> an reservations about this draft, it would be on architectural grounds.  The
> draft tries really hard to transfer priority information over the Internet
> and in a foreign environment.

This is my major concern about this protocol as well, as I note in the
PROTO writeup (which, unfortunately, can't be seen publicly because of
a limitation in the datatracker; perhaps I should post it here).  I'm
interested in hearing whether others share this concern, and what the
community consensus is about it.

Barry, document shepherd

---

From: Barry Leiba <[email-masked]>
Date: Thu, 1 Mar 2012 16:55:25 -0500

Also, because it's not publicly visible, here's my PROTO writeup for
this document:

The publication of draft-melnikov-smtp-priority as a Proposed Standard
is requested by an individual contributor.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document proposes a standard protocol extension to SMTP.  It is
possible for the proposal to go through as Experimental, but the
shepherd and the participants in the discussion of the document
believe that Proposed Standard is correct.  The strongest argument for
Experimental is probably the new mechanism of tunneling the SMTP
parameters through servers that don't support them by using reserved
message header fields (see more below).

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

 Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This defines an extension to SMTP whereby messages are sent with a
"priority", enabling the receiving Message Transfer Agent to take the
priority into account for onward processing.  The goal is to process
and/or transfer higher priority messages first.

 Working Group Summary

  Was the document considered in any WG, and if so, why was
  it not adopted as a work item there? Was there controversy
  about particular points that caused the WG to not adopt the
  document?

There are currently no appropriate email-related working groups.  The
ADs and AppsAWG chairs considered the document for the Apps Area WG,
but decided that it would be done best as an individual submission,
and did not need the attention of the working group.

 Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There is at least one prototype implementation, and plans for at least
one other after publication.  This is largely being done for a
particular use case, and the proponents are aware of some of the
tradeoffs they've made.  The shepherd has some concern about the
broader applicability of this as a standard, given those trade-offs.
That said, some of them had to be made, and there is value in
implementing features from proprietary email systems in standardized
ways on the open Internet.  The shepherd supports that general effort.

 Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Barry Leiba is the document shepherd; Pete Resnick is the Responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed several versions of the document as it has progressed
through the stages of discussion and modification, and I think this
version is ready to go forward.  I would like IETF community input on
some of the trade-offs, particularly those created by the parameter
tunneling and those involving the trust model (see below).

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The document has had sufficient review from the email community, on
the ietf-smtp list and through individual reviews.  I have no concerns
about the level of review.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

I would like to see SecDir and OpsDir reviews during the last-call process.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here.

The most significant item that needs to be called out is the issue of
tunneling the PRIORITY value through non-conforming MTAs by turning it
into a message header field (MT-Priority) and then back again.  This
is a problematic technique, but is an important capability for those
who need and intend to implement this extension.  It creates a trust
issue, wherein a message containing MT-Priority can be originated with
a Message Submission Agent that does not know about this extension,
and when the message hits a Message Transfer Agent that does support
this, the header field will be turned back into a valid PRIORITY
value, on the unwarranted assumption that it was authorized.
Intermediate MTAs have no way to distinguish this situation from one
where the field was tunneled legitimately.

The counter-argument is that the use case for this specification
involves out-of-band trust relationships, and that such situations
will be known and dealt with.  I believe that limits the usability of
those features on the open Internet, with other use cases.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.

No, and there are no known IPR issues with this document.

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

The consensus for this is solid, but relatively small.  A number of
participants/reviewers have expressed interest in the concept, though
it's not clear how much implementation is planned.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The document refers to iana.org URLs at the shepherd's request, to
make it clear which registries are being referenced.  These URLs will
be removed before RFC publication.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal reviews are needed.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There is a normative reference to RFC 2033 (LMTP), which is
Informational.  This needs to be called out in the last-call note.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.

No documents are modified by this one.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The document contains several IANA actions, which are all clearly
specified and correct.  No new registries are created.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

I have run the usual idnits and ABNF checks, and all is OK.

---

From: SM <[email-masked]>
Date: Thu, 01 Mar 2012 14:08:33 -0800

Hi Barry,
>It certainly does, in the first paragraph:

I missed that.

>        [RFC6409] and LTMP [RFC2033].

And that one.

>community consensus is about it.

I read the PROTO writeup.  The other problem may be a bug.  I did not 
report it.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Mar 2012 22:16:03 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Thursday, March 01, 2012 1:36 PM
> To: [email-masked]
> Cc: Alexey Melnikov
> Subject: Re: Last Call: <draft-melnikov-smtp-priority-07.txt> (Simple
> Mail Transfer Protocol extension for Message Transfer Priorities) to
> Proposed Standard
> 
> priority information over the Internet and in a foreign environment.
> Although the draft is well-written and can be implemented, I have
> doubts about whether it will achieve its objective.  I unfortunately
> cannot support the publication of this draft as a Proposed Standard.

It's certainly true that this could be done as a pair of clustered drafts, but since they are clearly meant to be used together, and indeed have to be when tunneling priority information through non-participating environments, their coupling into a single draft makes sense to me.

Doubling the work of the IESG and the RFC Editor doesn't seem reasonable here.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Thu, 1 Mar 2012 18:00:51 -0500

Oh, it's absolutely true that if one is to define this sort of thing as a
combination of SMTP protocol and message header fields, that should be done
in a single specification.  What I'm interested in community input on is
whether the mechanism of transferring the information back and forth
between the two, and having SMTP protocol get involved in inspecting and
altering header fields is a good thing.

Barry, document shepherd

On Thursday, March 1, 2012, Murray S. Kucherawy wrote:

> > From: [email-masked] <javascript:;> [mailto:[email-masked]<javascript:;>]
> On Behalf Of SM
> > To: [email-masked] <javascript:;>
> > Cc: Alexey Melnikov
> It's certainly true that this could be done as a pair of clustered drafts,
> but since they are clearly meant to be used together, and indeed have to be
> when tunneling priority information through non-participating environments,
> their coupling into a single draft makes sense to me.
>
> _______________________________________________
> Ietf mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Mar 2012 23:38:22 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Thursday, March 01, 2012 3:01 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: Last Call: <draft-melnikov-smtp-priority-07.txt> (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard
> 
> Oh, it's absolutely true that if one is to define this sort of thing as a combination of SMTP protocol and
> message header fields, that should be done in a single specification.  What I'm interested in community input
> on is whether the mechanism of transferring the information back and forth between the two, and having SMTP
> protocol get involved in inspecting and altering header fields is a good thing.

It took me a bit of reading of older SMTP extension documents to realize that this was something new.  I had thought things like DELIVERBY did this, but I see now that's not the case.

To borrow some language from recent conversations that considered questions like this, it is only a /proposed/ standard we're talking about.

That said, are there any existing implementations of this that can speak to the question of unintended side effects?

-MSK

---

From: John Leslie <[email-masked]>
Date: Thu, 1 Mar 2012 18:54:19 -0500

> altering header fields is a good thing.

   Heck, I owe Barry an honest reply...

draft-melnikov-smtp-priority-07 states:
] 
] This document allows a message priority to be tunneled through MTAs
] which don't support the PRIORITY SMTP extension by specifying how it
] can be represented in the message itself (using the MT-Priority
] header field).  Thus it is important to ensure that an MTA receiving
] a message containing the MT-Priority header field can trust that it
] was set by an authorized agent.

   ROTFL. It could come from literally anywhere, including MTAs you
wouldn't think are on-path.

   However, the draft continues:
] 
] Such trust can be realized, for example, by using DKIM Section 12.1
] to sign the MT-Priority header field value, S/MIME, or by keeping a
] list of trusted senders (e.g. within a close environment) .

   This at least attempts to make the MT-Priority trustworthy.

   Myself, I don't think it's worth the trouble. DKIM positively invites
replay; I must be missing how S/MIME protects a header field; and lists
of trusted senders go out-of-date awfully quickly.

   I think tunneling like this is clever, but asking for trouble: and
I've seen too many instances of getting the trouble -- even without a
intentionally-bad actor.

   As to whether having SMTP protocol get involved in inspecting and
altering header fields is a good thing, that horse has left the barn;
nonetheless, it's error-prone and very vulnerable to bad-analysis in
the presence of known-bad actors.

   I believe I'd opt-out of paying any attention to MT-Priority.
Priority is fine along an unbroken path of trust, but IMHO should stop
at the first weak link.

   (Sorry, Alexey...)

--
John Leslie <[email-masked]>

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Mar 2012 11:27:43 +0900

> What I'm interested in community input on is whether the mechanism of
> transferring the information back and forth between the two, and
> having SMTP protocol get involved in inspecting and altering header
> fields is a good thing.

you're kidding, right?  talk about primrose path.  did you not notice
the three headed dog?  sheesh!

MTA should not muck with headers.

randy

---

From: [email-masked]
Date: Thu, 01 Mar 2012 22:12:05 -0800 (PST)

> where the field was tunneled legitimately.

There may not be substantial experience with doing this sort of thing in SMTP
relays, but there's plenty of experience doing it in gateways to other mail
environments, e.g., X.400 and many of the old LAN email systems. In fact one of
the more common fields that has been mapped this way is message transfer
priority, so there is considerably experience with fields having more or less
the same semantics as what is being proposed here.

I am unaware of any cases where this was abused, probably because increased
transfer priority doesn't buy you all that much in most cases. Related
but more user-visible features, e.g., importance (in the X.400 sense)
have been known to be abused, however.

That said, I think an important omission in this document is that it 
only allows MSA's to change message priorities to conform to site policy.
MTAs should also be allowed to do this.

Another issue is the silly prohibition against using Priority: and other header
fields to set priority levels. What if is existing site policy is in fact to
use those fields to determine message priority?

> those features on the open Internet, with other use cases.

Not if MTAs aren't also allowed to enforce site policy.

				Ned

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 2 Mar 2012 08:07:55 +0100

On 2 mar 2012, at 00:00, Barry Leiba wrote:

>  What I'm interested in community input on is whether the mechanism of transferring the information back and forth between the two, and having SMTP protocol get involved in inspecting and altering header fields is a good thing.

No, not change header fields.

  Patrik

---

From: Hector <[email-masked]>
Date: Fri, 02 Mar 2012 06:47:05 -0500

Barry Leiba wrote:

> What I'm interested in community input on is

I may be too old school, but I still believe "thou shall not tamper 
with mail" in principle, especially passthru.

Only with Network related control lines/headers that the transports 
deal with. If this header is one of these, I don't see an issue.

Also, in regards of the transport even processing the headers (which 
suggest analyzing the payload at DATA before the EOD response is 
issued), past concerns included the "delay factor", the scalability 
question, the dupe potentials, the current 10 min "timeout" too long 
and not always supported by clients, including ideas of using a "Keep 
Alive" for DATA shims that take too long.

If I understand where you going with this, IMV, I don't think it is a 
good thing SMTP systems should be expected will be processing the 
payload or its headers before the EOD is issued.

--
HLS

---

From: Barry Leiba <[email-masked]>
Date: Fri, 2 Mar 2012 09:26:48 -0500

On Fri, Mar 2, 2012 at 6:47 AM, Hector <[email-masked]> wrote:
> If I understand where you going with this, IMV, I don't think it is a good
> thing SMTP systems should be expected will be processing the payload or its
> headers before the EOD is issued.

This document doesn't specify anything that needs header processing
*during* the SMTP transaction.[1]  The specified manipulation would
happen after the MTA had accepted the message, and before it relayed
it to the next hop, so I don't think there's any timeout-sensitive
issue here.

[1] It's possible that if an MTA should receive a high-priority
message that came through a non-supporting MTA immediately prior, AND
it wanted to reject the message based on the priority ("message too
big for the specified priority," or some such), then it would have to
find and parse the MT-Priority header field before giving the OK after
DATA.  That seems minimal, but perhaps it could be a problem.

Unrelated to Hector's note:
Does anyone's answer change if I point out that we already have at
least two protocols that have an MTA alter message header fields in
between message receipt and message relay?

An MTA that supports DKIM [RFC6376] might, under some conditions,
remove an existing signature and add its own.

An MTA that implements the Authentication-Results header field
[RFC5451] might remove an existing header and add its own.

Arguments can be made that the former is more of a gateway function
than a relay function (and Ned has already pointed out that we're
pretty sanguine about this sort of manipulation in gateways), and that
the latter is behaving more or less as a trace field, which we also
allow some flexibility with.  Also, those specifications aren't
directly part of an SMTP extension, so they're things that are
performed by a server that supports SMTP *and also* something else.
Whereas this manipulation is built directly into the SMTP extension,
as part of the protocol.

No opinions given here as a participant -- I'm trying to tease out the
issues for this document.

Barry, still shepherding

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 2 Mar 2012 17:59:45 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Friday, March 02, 2012 6:27 AM
> To: [email-masked]

That's a good example.

> [RFC5451] might remove an existing header and add its own.

Unfortunately I don't think this one is, because the header changes it encourages take place strictly within an ADMD (specifically, the receiving one), not as a mechanism for tunneling transport metadata through non-participating environments.

> allow some flexibility with.

RFC6376 also asks for trace header field treatment for DKIM-Signature.

That said, this does show that we've dabbled in this area of mushy boundaries, and the results haven't exactly been disastrous.

-MSK

---

From: Hector <[email-masked]>
Date: Fri, 02 Mar 2012 22:16:37 -0500

> it to the next hop, so I don't think there's any timeout-sensitive

Thanks Barry for your follow up.

I was provided input relative to the generality of your question 
regarding an "SMTP system" which you now provided a better specific 
example(s) to what I was referring to, case in point.

> remove an existing signature and add its own.

My question is "when" or does it matter?

Is its done during the SMTP session (DATA before the EOD response) or 
is it done after the mail is accepted?

I believe if done at DATA, then we are still talking the SMTP 
protocol. If it is done after the SMTP session, then its not really 
something we can say is still part of the SMTP protocol.

It also depends on the augmented protocol itself.

Example, as an DKIM implementator, the verification is only done at 
the SMTP DATA, no resigning or anything related to "CHANGE" is done 
here.  Anything close to that is completely outside of SMTP. But.....

> [RFC5451] might remove an existing header and add its own.

This is closer to a higher potential for SMTP systems to consider 
because of the nature and intent of new receiver message validations 
now using a AUTH-RES header to provide receiver processing "state" 
information to be either appended (a change) and/or additional 
AUTH-RES header added.

But there also the idea that you won't do (change) because AUTH-RES 
also provides the machine identity that did the checking and added the 
information.  So if there are now new state information to add, I 
would think you will see want to have some persistency and trace 
history of the different hops, machines that did the AUTH-RES state 
checks.

I was purely thinking in general terms of how/where an email augmented 
protocol would be expected to be implemented for quick plug and play 
operations.

To me, AUTH-RES "change" would fits better for your question when all 
done in the same ADMD. It is what might be expected and happen in 
adding new processing state information   DKIM verification and 
changes related to stripping/replacement (a already controversial 
subjective tampering idea) I would not expect to be "normally" done in 
a SMTP receiver.

Of course, its just one person opinion and one input only.

Thanks

--
HLS

---

From: "John Levine" <[email-masked]>
Date: 3 Mar 2012 04:11:53 -0000

>> for a SMTP extension specification to define a mail header field. ...

>community consensus is about it.

I have no problem logging stuff from the SMTP session into a message
header, we've been doing that since forever.  But I have a lot of
problem turning a header back into SMTP for a subsequent relay, for
two reasons.

One is just that it's ugly.  There were good reasons to separate the
envelope from the body back in the 1970s, and I think those reasons
are just as good now.  Over in the EAI group, there was a valiant
effort to tunnel EAI messages through non-EAI SMTP servers via
downgrades, and we eventually gave up.  Now, if you want to send an
EAI message, there has to be an EAI path all the way from the sender
to the recipient.  This isn't exactly analogous, but it's instructive.

The other reason is that I think it's too ill-specified to
interoperate.  The theory seems to be that the relay server notices an
MT-Priority: header, and (vigorous waving of hands) somehow decides if
the message has sufficient virtue to promote the header back into the
SMTP session.  The hand-waving is not persuasive; the suggestion of
S/MIME, which obviously won't work, is not encouraging.

If you want to brave the ugliness and standardize this, the spec needs
to explain how the server decides whether to believe an MT-Priority
header.  If it doesn't, it's too vague to interoperate.

So I have two suggestions.  One is to leave it as is, and make it
experimental. If it turns out the tunnels all work the same way, you
can come back and add the spec about how they work and rev it as
standards track.  The other is to take out the tunnel bit and make it
standards track now, so a compliant implementation needs
priority-aware MTAs from end to end.  Even if you take out the tunnel
stuff in the spec, you can still tunnel in your implementations, using
whatever non-standard ad hoc kludges you want.  Since the current spec
has gaps that would need to be filled by non-standard ad hoc kludges
anyway, you haven't lost anything.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: [email-masked]
Date: Sat, 03 Mar 2012 10:07:37 -0800 (PST)

> S/MIME, which obviously won't work, is not encouraging.

Both good points. While I personally am indifferent to header modification
being an issue - I believe we've long since crossed that bridge - I will also
note that simply changing this proposal to always insert the MT-Priority: field
at submission time and leave it unchanged throughout message transit would
leave most of the functionality intact and eliminate the header modification
issue entirely.

But the upleveling of header to envelope would remain. John is quite correct in
his assertion that these are mostly uncharted waters: The only remotely
comparable case I can think of is the mapping of some X.400 fields to the
NOTARY extension, but in that case the mapping was from X.400 envelope material
to SMTP envelope material. Additionally, the mapping was precisly specified
with no wiggle room for "site policy". 

I think this will likely lead to interoperability problems. Now, in the case
of message processing priority the chance of such problems causing significant
trouble seem pretty slim, but "it doesn't work well but it also doesn't
matter much" is not a justification I feel comfortable embracing.

> anyway, you haven't lost anything.

I have to say I strongly prefer the latter, especially if it also includes
eliminating the prohibition on using other sources of priority information to
set the envelope priority level on submission. In fact given that prohibition
I see little point in implementing this, at least not in a fashion
that conforms to the specification.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Mar 2012 11:13:04 +0000

> unnecessary, but where's the harm?
Agreed.
>     English words, absent their normative meanings.
I don't mind changing that, but ID-nits gives a warning when the text 
about keywords is changed and *everybody* likes to complain about that. 
Please talk to IESG about whether using a variant of the standard text 
is acceptable.
> My review, which was already sent to Alexey and Pete:
Agreed.
>        The syntax of the MT-Priority header field is specified in
Thanks, I've used your text.
> looks clearer and easier.
Ok, I will try to use your suggestion.
>    implementation might need an extra priority level beyond the 6 levels
Changed, thanks.
> Such actions usually require user interaction.
Ok.
>    priorites.
Removed as per reply to Pete.
> If two or more emails with the same priority are ready to
Ok.
>    maximum time allowed for delivery.
Ok.
> DELIVERBY extension alone does not guarantee any priority processing."
Added.
> I would switch sections 6 and 7, to avoid the forward reference in the
Ok.

  [snip]

Thank you,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Mar 2012 11:59:51 +0000

Hi Murray,
Thank you for the comments. Some answers below.

On 01/03/2012 04:43, Murray S. Kucherawy wrote:
> I have several comments on this draft.  But first, this is a big improvement since the last version I reviewed, so kudos to the authors.
>
> A couple of these refer to issues in the document that need to be resolved before it can move forward, but you probably already know what they are.  The rest are not showstoppers.  It could also use a quick editorial pass, which I'm happy to do for you separately if you like.
>
> - Section 3, bullet 7: LTMP ->  LMTP
Fixed.
> - Section 4.1 contains a reference to "esmtp-values" which looks like an ABNF terminal, but it's not explained.  Did you mean an ABNF terminal,
Yes, as defined in Section 4.1.2 of RFC 5321. Clarified.
> or did you mean something about ESMTP parameters?
>
> - Section 4.2, bullet 2: "Section 6" should probably be in parentheses, probably preceded by "see"
Fixed.
> - There's a bunch of TBDs that still need to be resolved before this document moves forward (X.7.TBD3 as an enhanced status code, for example)
No, these are assigned by IANA before publication. RFC Editor will fix 
these.
> - Section 4.2 makes reference to "the Minimize condition" but the document doesn't otherwise define it
Yes, I will explain.
> - Section 4.3 says "For example, once an MTA accepts a message, the MTA MUST NOT change a (syntactically valid) priority value if the MTA doesn't support it."  There seems to be a chicken-and-egg going on here: If the MTA doesn't support the extension, how can it know not to change the priority outbound?
I meant "supports the extension, but doesn't support a particular value 
as distinct priority level". Suggestions on how to make this clear would 
be appreciated.
> - There are lots of SHOULDs in here that might benefit from example situations in which one might deviate from the normative statement containing the SHOULD.
I will review. I had some discussion with SM about some of these and 
argued that not all of them should be explained. But I agree that some 
of them need explanation.
> - Section 5 and Section 5.1 use "not required", "should", and "may" where RFC2119 is cited earlier.  Should they be in all-caps, or should other language be selected?
Lowercased versions are not used in normative sense. Maybe a note 
suggested by Barry would help with this.
> - Section 5: "Irrespectively on" ->  "Irrespective of"
Changed.
> - Section 5: "fine grainer control" ->  "finer-grained control"
Changed.
> - Section 5.1 makes reference to "the work-in-progress effort extension to RSVP that prioritizes reservations."  This should include a citation even if it references an I-D that's not published yet.
Ok, I will ask my co-editor about this.
> - Section 9: "it is advised that all or none of them SHOULD support the PRIORITY extension" sounds awfully mushy.  I suggest dropping the SHOULD, and rather say something like "it is advised that either all of them support the PRIORITY extension, or none do".
Ok.
> - Section 10 should be resolved before the document advances.
>
> - Section 11: Why use "PRI" and not "priority"?  The existing set of Received clause names are lowercase words, so it seems strange to deviate.
I don't mind to switching to "PRIORITY". But section 4.4 of RFC 5321 
uses uppercase variants (and yes, I know they are case insensitive).
> - Appendix A: Can STANAG 4406 be listed in the Informative References?
Sure.
> - Appendix D: "This appendix and its subsections are informative."  I think that (a) any appendix is informative, because normative text doesn't belong in an appendix; and (b) the normative stuff uses RFC2119 language and this doesn't.  Thus, I think this sentence should be removed.  (I know I've lost this argument before, but I'll make another stand here anyway.)
I think other people already commented on this :-)

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Mar 2012 14:12:01 +0000

Hi Ned,

> the same semantics as what is being proposed here.
Exactly.
> MTAs should also be allowed to do this.
Can you elaborate a bit more on possible use cases? Would such an MTA 
only lower the priority or do you think it might also raise it?
> use those fields to determine message priority?
(Ignoring the question of whether use of MT-Priority header field is a 
good thing or not for a moment.)

I actually don't have a strong feeling against usage of other existing header fields.
Some of the existing header fields don't have the exact semantics desired here. Others (like the MIXER's Priority) have the right semantics but don't support sufficient number of priorities required by MMHS (6 levels). That is why a new header field was introduced.

But anyway, I am happy for this restriction to be removed/relaxed. Can you recommend some specific text?

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Mar 2012 14:45:44 +0000

On 03/03/2012 18:07, [email-masked] wrote:
  [...]
> that conforms to the specification.
I do prefer the latter as well (and yes, happy to remove the restriction), but I don't feel very comfortable pretending that tunneling wouldn't happen. See my other reply about this (to be written later today).

---

From: Barry Leiba <[email-masked]>
Date: Mon, 5 Mar 2012 10:15:32 -0500

Ned:
>> Another issue is the silly prohibition against using Priority: and other
>> header fields to set priority levels. What if is existing site policy is in fact
>> to use those fields to determine message priority?

Alexey:
> Some of the existing header fields don't have the exact semantics desired
> here. Others (like the MIXER's Priority) have the right semantics but don't
> support sufficient number of priorities required by MMHS (6 levels). That is
> why a new header field was introduced.

Right, this is the issue I have with Ned's desire to allow use of
other fields: those fields have inconsistent semantics, and
inconsistent and non-standard usage.  They're often used to indicate
visual importance of the message to the MUA, rather than anything
related to transmission priority.

That said, I'd have no problem with some sort of MAY-level permission
to *MSAs* to use these fields.  I'd feel very uncomfortable allowing
*MTAs* to do it.  Ned, would it be adequate to your needs to handle it
that way?  Something like this:

OLD
   Other message header fields, such as Importance [RFC2156], Priority
   [RFC2156] and X-Priority, MUST NOT be used for determining the
   priority under this "Priority Message Handling" SMTP extension.

NEW
   Other message header fields, such as Importance [RFC2156], Priority
   [RFC2156] and X-Priority, are used inconsistently and often with
   different semantics from MT-Priority.  Message Submission Agents
   [RFC6409] MAY use such fields to assign an initial priority in the
   absence of an SMTP PRIORITY parameter.  Otherwise, such fields
   MUST NOT be used for determining the priority under this "Priority
   Message Handling" SMTP extension.

Barry

---

From: "John R. Levine" <[email-masked]>
Date: 5 Mar 2012 10:41:56 -0500

> I do prefer the latter as well (and yes, happy to remove the restriction), 
> but I don't feel very comfortable pretending that tunneling wouldn't happen.

Of course people will tunnel stuff.  But will they all tunnel it the same 
way, in which case a standard could be useful, or will they each have 
their own hacks?  Given the vagueness about how you can tell that 
something should come out of the tunnel back into the envelope, it sounds 
more like the latter.

Regards,

---

From: [email-masked]
Date: Mon, 05 Mar 2012 07:34:30 -0800 (PST)

> Can you elaborate a bit more on possible use cases?

Nobody is going to simply allow priorities to be set willy-nilly on mail coming
from random sources outside their administrative domain. That's absurd.
However, they may be will to make bilateral arrangements with selected
partners, identified by IP address or whatever, that would allow such a
setting, perhaps within a restricted range of allowed values.

> Would such an MTA

I don't see any reason to limit it to lowering it.

> I actually don't have a strong feeling against usage of other existing
> header fields.  Some of the existing header fields don't have the exact
> semantics desired here.

Well, sure. You most definitely don't want to mix in Importance or other
MUA level priority fields.

> Others (like the MIXER's Priority) have the right semantics but don't support
> sufficient number of priorities required by MMHS (6 levels).

I think you're going to have to accept the fact that the overwhelming majority
of people out there running email systems have never even heard of MMHS and
even if they have don't give a damn about faithfully retaining it's
semantics. But they do care that new mechanism be made compatible with
whatever ad-hoc scheme they are currently using, even if said scheme
doesn't have the full range of values.

For example, I can easily see a site wanting to map this to and from the field
used by Microsoft Exchange (sorry, I forget the exact name) even though if
memory serves that field only accepts three values. And either this is going to
happen no matter what the specification says, or the specification simply won't
deploy in any meaningful way.

> That is why a new header field was introduced.

> recommend some specific text?

I'll try to do so later this week.

				Ned

---

From: [email-masked]
Date: Mon, 05 Mar 2012 07:47:24 -0800 (PST)

> > header fields.

> related to transmission priority.

I'm sorry, but that's simply a strawman. AFAICT nobody pushing back on this is
suggesting mapping MTA priority to or from a field with totally different
semantics. But there are plenty of fields in common use that are used to
control MTA priority. Those are the fields I'm talking about.

And yes, people will make mistakes. They always do. But as I commented
in a previous discussion, if we let that stop us we'd never standarize
anything.

> that way?

No. Like it or not, if you expect this to gain any traction at all, you're
going to have to accept the fact that people are going to want to tunnel it
through fields with the same general semantics but restricted as to possible
values.

>    priority under this "Priority Message Handling" SMTP extension.

I hadn't noticed importance listed as a possible source of MTA priority
information. That's actually committing the error of mapping a field with
entirely different semantics into MTA priority and at a minimum needs to be
removed - we should NOT be encouraging that.

>    Message Handling" SMTP extension.

It seems you're complaining about other people doing something they never
wanted to do while actually making that error yourself.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Mon, 5 Mar 2012 11:07:16 -0500

> wanted to do while actually making that error yourself.

I have no idea what you mean, so perhaps you can be more specific
about what it is that you want to do.

Barry

---

From: SM <[email-masked]>
Date: Mon, 05 Mar 2012 08:30:00 -0800

>anyway, you haven't lost anything.

Here's the other side of the coin.

A careful review of the draft would show that the authors thought 
about the idea very carefully and they have good specification and 
implementation experience.  The easy path would be to make this Experimental.

As John Levine mentioned above, there is an alternative to get this 
on the standards track.  The specification could be in three parts, 
one for the SMTP extension, the second for the header field, and the 
last one is about how the technologies are applied.  I didn't think 
about the alternative when I went through -04.

Most of the text from Section 12 would go into the third part.   I 
wouldn't go too much into trust; it may be easier to make use of 
local policy or "use cases".  If I am not mistaken, the old version 
of the proposal used that approach.  Bullets 2 and 3 of Section 4.2 
and bullet 2 of Section 4.4 could be moved to the third part, 
together with the note in bullet 1 of Section 4.3.   The header 
restriction for a MSA is permitted through compliance with site 
policy (Section 12).  Getting into S/MIME entails having to deal with 
outer and inner headers.  It's easier not to get into that.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Mar 2012 18:00:12 +0000

> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Monday, March 05, 2012 4:00 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> > - There's a bunch of TBDs that still need to be resolved before this
> > document moves forward (X.7.TBD3 as an enhanced status code, for
> > example)
> 

OK, I've just never seen that approach taken before.

> > - Section 4.3 says "For example, once an MTA accepts a message, the
> MTA MUST NOT change a (syntactically valid) priority value if the MTA
> doesn't support it."  There seems to be a chicken-and-egg going on
> here: If the MTA doesn't support the extension, how can it know not to
> change the priority outbound?
> 
> as distinct priority level". Suggestions on how to make this clear
> would be appreciated.

Suggest:

For example, once an MTA accepts a message, the MTA MUST not change a (syntactically valid) priority value if that value is not supported by the MTA's implementation of this extension.

> > - There are lots of SHOULDs in here that might benefit from example
> > situations in which one might deviate from the normative statement
> > containing the SHOULD.
>

There are some that are in more need of this than others, and I know lately that I've been thanked by ADs during IESG evaluation for providing this kind of text, so it can only help where it's possible to provide it.

> > - Section 5 and Section 5.1 use "not required", "should", and "may"
> > where RFC2119 is cited earlier.  Should they be in all-caps, or should
> > other language be selected?
> 

Sure, and I sympathize with your reply that it triggers an ID nit.  I wonder if the IESG could agree on some text like what Barry suggested and add it to the ID nit checker as a valid exception.  Maybe 2119 should also be updated accordingly.

> > - Section 11: Why use "PRI" and not "priority"?  The existing set of
> > Received clause names are lowercase words, so it seems strange to
> > deviate.
> 

I don't think I've ever seen them in the wild, which is why it caught my attention.

> > - Appendix D: "This appendix and its subsections are informative."  I
> > think that (a) any appendix is informative, because normative text
> > doesn't belong in an appendix; and (b) the normative stuff uses
> > RFC2119 language and this doesn't.  Thus, I think this sentence
> > should be removed.  (I know I've lost this argument before, but I'll make
> > another stand here anyway.)
> 

Those people are also no longer on my Christmas list.  :-)

Thanks,
-MSK

---

From: Barry Leiba <[email-masked]>
Date: Mon, 5 Mar 2012 14:40:57 -0500

> I don't mind changing that, but ID-nits gives a warning when the text about
> keywords is changed and *everybody* likes to complain about that. Please
> talk to IESG about whether using a variant of the standard text is
> acceptable.

I've used text like this before, and the IESG has never objected to
it.  One advantage with this formulation, which uses the standard 2119
text and *appends* to it, is that idnits likes it and doesn't generate
a warning.

Barry

---

From: [email-masked]
Date: Mon, 05 Mar 2012 18:24:01 -0800 (PST)

> text and *appends* to it, is that idnits likes it and doesn't generate

More generally, ID-nits is supposed to be helpful. Straightjackets are not
helpful.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Mon, 5 Mar 2012 21:30:17 -0500

> More generally, ID-nits is supposed to be helpful. Straightjackets are not

I absolutely agree.  And even in cases where my alternative 2119 text
has generated idnits complaints, the IESG didn't care.  They only
cared that the text accurately explained the terms the document used.

Barry

---

From: [email-masked]
Date: Mon, 05 Mar 2012 18:56:34 -0800 (PST)

> something should come out of the tunnel back into the envelope, it sounds

If the only issue was tunneling, I'm not sure it would matter as much as it
does. After all, if we have a spec that says use MT-Priority and someone
uses something else within their ADMD, who will even know?

But this isn't just about tunneling. There are a bunch of ad-hoc priority
mechanisms out there, some in fairly widespread use. If we cannot align
ourselves with those nobody is going to be interested in deploying this
extension. Instead they will be asking us to retain our present capability of
interoperating with those existing systems. And doing both is ... messy to say
the least, not to mention a violation of the current language in the
specification.

				Ned

---

From: [email-masked]
Date: Mon, 05 Mar 2012 19:02:21 -0800 (PST)

> about what it is that you want to do.

I'm talking about the inclusion of Importance: in both the original and revised
text as a field we're suggesting might make sense to map. It should not be
there - the semantics are not compatible with MTA priority. And even if you
think it makes sense that messages marked "important" in the MUA should receive
an MTA priority boost, allow me to point out that by GOSIP rules (which are
still in effect in some places) elevated MTA priority is used to shorten the
time messages are retained before returning them as undeliverable. That's
really not a good idea to do for all messages marked "important", and some
people with systems that do this are probably unaware of the behavior.

Mind you, I have no problem with someone doing it because it makes sense in
their case. But we should not be suggesting doing it in the text, and getting
into a discussion of the pitfalls of doing it doesn't is unnecessarily
distracting.

The semantics of X-Priority are less clear. It's sometimes used for MTA
priority setting, other times it's been an MUA field. AFAIK it has never had
the problematic semantics I just discussed. Mapping it is therefore a judgement
call implementations should be allowed to make, and that makes it a good
example to include in this sort of text.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Mon, 5 Mar 2012 22:23:01 -0500

On Mon, Mar 5, 2012 at 22:02, Ned Freed <[email-masked]> wrote:
> there - the semantics are not compatible with MTA priority.

Ah, OK.  So there's no strawman that I've been constructing, or any such.

Alexey had just included Important, along with Priority and
X-Priority, as an example of other priority-like fields that he didn't
want implementations to use for this purpose.  When you balked at the
blanket ban, I proposed an alternative that just called out the same
set of fields.

What we need is replacement text that makes sense: that says which
(known) fields can maybe-kinda-sorta-ifyouhaveto be used here, and
which ones absolutely can't (wrong semantics).  I think such advice is
important if we're going to keep the tunneling thing in here.  If
you'd like to take a stab at suggesting replacement text, I, and I
think Alexey, would be very grateful.  You have a much better idea
than I do of what actual use is being made of the different fields
currently.

> priority setting, other times it's been an MUA field.

That's why I added "inconsistently" into my text.

So... can we get text that gives the proper fields, the proper
warnings, the proper MAYs, SHOULDs, and MUST NOTs, and all that?

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Mar 2012 21:54:27 +0000

> text and *appends* to it, is that idnits likes it and doesn't generate
Ok then.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Mar 2012 22:24:41 +0000

On 05/03/2012 18:00, Murray S. Kucherawy wrote:
>> Cc:[email-masked]
>> Subject: Re: Last Call:<draft-melnikov-smtp-priority-07.txt>  (Simple
>>> - Section 4.3 says "For example, once an MTA accepts a message, the MTA MUST NOT change a (syntactically valid) priority value if the MTA
Ok, changed.
> There are some that are in more need of this than others, and I know lately that I've been thanked by ADs during IESG evaluation for providing this kind of text, so it can only help where it's poss…
Sure. I've asked for explanation while I was on IESG as well.

> I don't think I've ever seen them in the wild, which is why it caught my attention.
I've changed "PRI" to "PRIORITY" in my copy.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Mar 2012 22:33:16 +0000

Hi Ned,

Agreed.
> setting, perhaps within a restricted range of allowed values.
Right. Not allowing this actually bothered me. So I've reworded to allow 
for that.
> deploy in any meaningful way.
Ok, I tend to agree. Our implementation will do this kind of mapping in 
absence of MT-Priority anyway.
>> But anyway, I am happy for this restriction to be removed/relaxed. 
>> Can you
>> recommend some specific text?
>
Is the following better:

<t>The Importance <xref target="RFC2156"/> header field MUST NOT be used 
for determining
       the priority under this "Priority Message Handling" SMTP extension.
       In absence of both the PRIORITY MAIL FROM parameter and the 
MT-Priority header field,
       other message header fields, such as Priority <xref 
target="RFC2156"/> and X-Priority,
       MAY be used for determining the priority under this "Priority 
Message Handling" SMTP extension.
</t>
?

---

From: Barry Leiba <[email-masked]>
Date: Tue, 6 Mar 2012 09:35:43 -0500

> Is the following better:
>
> <t>The Importance <xref target="RFC2156"/> header field MUST NOT be used for
> determining
>      In absence of both the PRIORITY MAIL FROM parameter and the MT-Priority
> header field,
>      other message header fields, such as Priority <xref target="RFC2156"/>
> and X-Priority,
>      MAY be used for determining the priority under this "Priority Message
> Handling" SMTP extension.
> </t>

What I don't like about that are:
1. It forbids using Importance, but doesn't say *why*, which could
invite misuse of other similar fields that are floating around.
2. I think MAY is fine for MSAs, but too weak for MTAs.  I accept what
Ned says, that MTAs will do this regardless of what we say.  That can
argue against MUST NOT, but I think SHOULD NOT is appropriate.  I
think the *standard* does want to discourage it, even while accepting
that it will happen.

I'd still like to wait for Ned's version of some text.  While we wait,
let me alter my earlier proposal and re-propose it here:
----------------------------
  Other message header fields, such as "Importance" [RFC2156],
  "Priority" [RFC2156] and "X-Priority", are used inconsistently and
  often with different semantics from MT-Priority.  Fields, such as
  "Importance", that are used to show a sense of importance to the
  end user are particularly ill-suited to convey transport priority, as
  these are distinct aspects of a message. Fields used inconsistently,
  such as "X-Priority", are problematic in this regard: we don't know
  what the intent was when the field was added.

  Therefore:

  1. Message header fields that have a sense of showing importance
  to the end user MUST NOT be used to determine the priority under
  this SMTP extension.

  2. Message Submission Agents [RFC6409] MAY use other header
  fields that have a sense of transport priority in order to assign an
  initial priority in the absence of an SMTP PRIORITY parameter.

  3. Message Transfer Agents handling messages after submission
  SHOULD NOT use any field other than MT-Priority to determine the
  priority under this SMTP extension.
----------------------------

Are we getting close?

Barry

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 06 Mar 2012 17:41:18 +0100

On 3/3/12 7:07 PM, [email-masked] wrote:
>>>> This draft also defines the MT-Priority header field. �It is quite unusual

+1

And there's another issue, I think. As there is 'upleveling of header to 
envelope', the draft also describes the reverse process. In par. 4.4 an 
SMTP client that talks to a non-confirming SMTP server MUST add it's own 
MT-Priority header with a priority determined by the process described 
in par. 4.2. This means an MTA can receive a mail with priority 
determined by envelope information and sends the message using header 
information. Those of us who wrote SMTP client software are in a better 
position to comment on this than I am. But having dealt with different 
MTA's it strikes me as fairly unusual for an SMTP client to add 
headerlines to the message-in-transit at such a late stage during 
transmission of the message to the SMTP server.

/rolf