Subject: Re: [apps-discuss] APPSDIR review of draft-melnikov-smtp-priority-09

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Apr 2012 20:34:11 +0100

Hi Claudio,
Thank you for the review and sorry for the delayed response: I've 
started writing some replies, but I only now got around to updating my 
copy of the document.

On 28/03/2012 17:12, Claudio Allocchio wrote:
>
> I have been selected as the Applications Area Directorate reviewer for 
> this draft (for background on appsdir, please see 
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
>
> Please resolve these comments along with any other Last Call comments 
> you may receive. Please wait for direction from your document shepherd 
> or AD before posting a new version of the draft.
>
> Document: draft-melnikov-smtp-priority-09
> Title: Simple Mail Transfer Protocol extension for Message Transfer 
> Priorities
> Reviewer: Claudio Allocchio, GARR
> Review Date: March 28th 2012
> IETF Last Call Date: 2012-03-28
> IESG Telechat Date: n/a
>
> Summary:
>
> In its declared scope, this document provides a mechamism (and 
> implementation suggestions) in order to enble a "real" priority 
> delivery service into the global e-mail handling scenario.
>
> However, it also introduces a concept idea on how to "tunnel" new SMTP 
> parameters requests via MTAs which do not support and ignore them, 
> embedding them into e-mail Heders fields. In doing this it breaks the 
> ideal separation between Envelope (SMTP) and Content (Headers and 
> bodyparts) in a different a new way than it was done before, because 
> is causes Headers to be able to modify Envelope parameters. There is 
> no negative consideration in this, but this feature should also be 
> stated more explicitly in the introduction.
Right. Based on IETF LC feedback and after talking to Apps AD the plan 
is to split the document into 2: one will describe a pure SMTP extension 
(with no tunneling) and will be targeted at Proposed Standard. Another 
one will be an Experimental document that talks about tunneling and 
gatewaying. So I will have more explicit text about this in the latter 
document.
>
> In general the document is well specified, and no major technical 
> issues are present. However I suggest yet another turn of consideraion 
> for the state iself of the specification: the WG and many others 
> propose to go into Standards Track, but in order to do this there are 
> at least some more exlicit considerations to clarify into the text 
> itself. Also, it is not easy to guess what will be the adoption level 
> of this mechanism,
That is true.
> and the risk introduced by possible inaccurate implementations shall 
> also be evaluated before going Proposed Standard.
Can you be more specific here?

A MTA implementation which accepts the PRIORITY parameter and ignores it 
is not particularly harmful. An implementation that treats higher 
priority messages as lower priority messages is, well, broken. So I am 
not entirely sure what are you thinking about here.
> Major Issues:
>
> The first major issue is non-technical. The e-mail service via SMTP 
> (and gateways and other related transport protocols) is best-effort, 
> often first-in/first-out based. And by itself, e-mail is a non 
> real-time service,
In practice I might disagree with you on that, although I see your point.
> like a chat, or text broadcast services: it is delivered into a 
> mailbox where the recipient will read it at his/her will. Although 
> many mail clients now uses a push-like model, delivering messages on 
> "always on" devices, the proposed new service extension aims to 
> provide differentiated service among messages. As correctly stated 
> into the document iself, there is a parallel between this and network 
> transport level services, where packets are prioritised. But also in 
> this case, the proposed mechanism will start to produce benefits only 
> when congestion in some parts of the mail transport system exists. 
> When congestion does not exist, the mechanisms will not result in 
> better service. This is not a drawback, but it should be stated more 
> explicitly in the document. Maybe expanding it into the 5.4 section, 
> where comparison with RFC2474 and RFC2205 are done.
Good point. I will add some text about that.
>
> The other major issue to consider is the global trust model which is 
> needed to implement the mechanisms. There are suggestions in the 
> specification on how to enhance security when tunnelling across non 
> supporting MTAs, for example, but in the document there are also other 
> suggestions which consider the extension applicable easily only within 
> restricted trusted communities.
This extension pretty much requires establishing of some trust between a 
sender and a recipient. I will make sure this is clear in the document. 
Some relevant text is already in the Security Considerations, but I will 
make it stronger.
> This apparently contradictory point shall be explained better. If this 
> specification is going Proposed Standard, it shall be crystal clear 
> about these scenarios, because implementers who did not take part in 
> the original discussion will implement it, and thus all 
> pre-assupmtions made during the discussion process of the 
> specification discussion will not be available for them.
>
> Minor Issues:
>
> There is no discussion (explicit) about how this specification 
> interacts/interferes with anti-spam techniques like graylisting / 
> whitelisting. Section 5.1 suggests that shorter retry times shall be 
> used for higher priority messages, but it does not mention at all 
> graylisting, for example. This should be explicitly mentioned, and 
> some guidance / suggestion given, to ensure a coherent behaviour.
As this extension requires some form of trust relationship and 
authentication (whether using SMTP AUTH, TLS, IP address whitelist, 
etc.), then greylisting should be disabled. But if you think this should 
be explicitly mentioned, I can mention it.
> The sentence in section 2 "The most important reason for emails to be 
> delayed is a transient error response from the next MTA to which the 
> email must be transferred." should also explicitly refer to the 
> graylisting case (which also causes often a "reply" message to be 
> delivered before the original message is).
Actually, I would rather delete the whole paragraph, as it doesn't add 
value to the spec (the definition is not used anywhere). Besides 
greylisting will cause transient errors.
> Section 4.2: why allowing an X-something like X-Priority to be used?
Because it is widely used (due to Exchange and some MUAs).
> I understand why not "Importance" and why yes "Priority"... but...
> Maybe this specification should "update" or even attempt to Obsolete 
> partially RFC2156?
I don't think it would be a good idea to touch RFC 2156. What do you 
think is broken in it anyway?
> Section 4.5: the text say that in case of mailing lists and aliases 
> the Header parameters tunnelling this specification extension SHOULD 
> retain the original priority. What about the many implementations 
> where headers are completely re-written and many parameters just 
> disappear? Some sentence should be given about this case, too.
Can you suggest some specific case? SHOULD is here is exactly to address 
this kind of case, but I have hard time explaining why it can be 
violated in general terms.
> Section 4.6... not all "non e-mail" environment allow addition of an 
> "header field"... how do we handle this?
Are you talking about the following text:

    1.  If the destination environment is unable to provide an equivalent
        of the MT-PRIORITY parameter, the conforming MTA SHOULD behave as
        if it is relaying to a non-conformant SMTP (Section 4.4).

? (Which would imply adding a header field for tunneling the priority)
If yes, I can clarify that this might be an exception.
>
> Section 9: given the current architecture, I'm very worried this will 
> ALWAYS happen (different behaviours because different support at 
> various MX-pointed servers). I'd make the consideration more explicit 
> and suggest a stronger guidance.
Can you suggest an improved text? I've changed "advised" to "strongly 
advised", but have troubles improving this text.
>
> Appendix A, B, C are very environment specific. Appendix A and C, 
> however, seem very specific environment related (the NATO messaging 
> military convetions for "A" and the USA Civil Protecion service for 
> "C"). While "B" is really global, beacause it maps OSI X.400 service, 
> the other two appendix seems too environment specific for an 
> international standard RFC specification. I would suggest handling at 
> least "A' and "C"  not as appendixes of this document, but as separate 
> short "mapping specification", also to enable further similar 
> documents to be published/registered more easily for other environments.
As per my comment above, most of these will move to a separate 
specification about tunneling.

Best Regards,
Alexey

---

From: Claudio Allocchio <[email-masked]>
Date: Sun, 22 Apr 2012 17:43:07 +0200 (CEST)

Hello Alexey,

On Wed, 18 Apr 2012, Alexey Melnikov wrote:

> Hi Claudio,
> Thank you for the review and sorry for the delayed response: I've started 
> writing some replies, but I only now got around to updating my copy of the 
> document.

no problem, we are all quite busy!

See inline.

>> implementation suggestions) in order to enble a "real" priority delivery 
>> service into the global e-mail handling scenario.
>> 
>> embedding them into e-mail Heders fields. In doing this it breaks the ideal 
>> separation between Envelope (SMTP) and Content (Headers and bodyparts) in a 
>> different a new way than it was done before, because is causes Headers to 
>> be able to modify Envelope parameters. There is no negative consideration 
>> in this, but this feature should also be stated more explicitly in the 
>> introduction.
> Right. Based on IETF LC feedback and after talking to Apps AD the plan is to 
> split the document into 2: one will describe a pure SMTP extension (with no 
> tunneling) and will be targeted at Proposed Standard. Another one will be an 
> Experimental document that talks about tunneling and gatewaying. So I will 
> have more explicit text about this in the latter document.

Very good solution!

>> In general the document is well specified, and no major technical issues 
>> are present. However I suggest yet another turn of consideraion for the 
>> state iself of the specification: the WG and many others propose to go into 
>> Standards Track, but in order to do this there are at least some more 
>> exlicit considerations to clarify into the text itself. Also, it is not 
>> easy to guess what will be the adoption level of this mechanism,
> That is true.
>> and the risk introduced by possible inaccurate implementations shall also 
>> be evaluated before going Proposed Standard.
> A MTA implementation which accepts the PRIORITY parameter and ignores it is 
> not particularly harmful. An implementation that treats higher priority 
> messages as lower priority messages is, well, broken. So I am not entirely 
> sure what are you thinking about here.

I was considering not specifically the "PRIORITY" case, but in general the 
idea of the parameters tunneling which is introduced. Of course a 
mismatched PRIORITY request is not harmful, but if another more essential 
parameter is tunnelled and lost in transactions (imagine a DSN reuqest for 
example, if somebody decides to use the mechanism to bypass non DSN 
conformat e-mail systems...) then it can be harmful. Thus I was 
considering a possible future scenario, and that's why I was sggesting 
Experimental for the tunnelling mechanism. As you will split documents, my 
suggestion is fully accomplished :-)

>> Major Issues:
>> 
>> The first major issue is non-technical. The e-mail service via SMTP (and 
>> gateways and other related transport protocols) is best-effort, often 
>> first-in/first-out based. And by itself, e-mail is a non real-time service,

I kno people tend to consider e-mail as a real time way to get information 
to somebody... I do it myself... but, theoretically, we cannot complain if 
somebody reads the information one week later :-)

>> like a chat, or text broadcast services: it is delivered into a mailbox 
>> where the recipient will read it at his/her will. Although many mail 
>> clients now uses a push-like model, delivering messages on "always on" 
>> devices, the proposed new service extension aims to provide differentiated 
>> service among messages. As correctly stated into the document iself, there 
>> is a parallel between this and network transport level services, where 
>> packets are prioritised. But also in this case, the proposed mechanism will 
>> start to produce benefits only when congestion in some parts of the mail 
>> transport system exists. When congestion does not exist, the mechanisms 
>> will not result in better service. This is not a drawback, but it should be 
>> stated more explicitly in the document. Maybe expanding it into the 5.4 
>> section, where comparison with RFC2474 and RFC2205 are done.

ok.

>> The other major issue to consider is the global trust model which is needed 
>> to implement the mechanisms. There are suggestions in the specification on 
>> how to enhance security when tunnelling across non supporting MTAs, for 
>> example, but in the document there are also other suggestions which 
>> consider the extension applicable easily only within restricted trusted 
>> communities.
> sender and a recipient. I will make sure this is clear in the document. Some 
> relevant text is already in the Security Considerations, but I will make it 
> stronger.

ok.

>> specification is going Proposed Standard, it shall be crystal clear about 
>> these scenarios, because implementers who did not take part in the original 
>> discussion will implement it, and thus all pre-assupmtions made during the 
>> discussion process of the specification discussion will not be available 
>> for them.
>> 
>> Minor Issues:
>> 
>> whitelisting. Section 5.1 suggests that shorter retry times shall be used 
>> for higher priority messages, but it does not mention at all graylisting, 
>> for example. This should be explicitly mentioned, and some guidance / 
>> suggestion given, to ensure a coherent behaviour.

> As this extension requires some form of trust relationship and authentication 
> (whether using SMTP AUTH, TLS, IP address whitelist, etc.), then greylisting 
> should be disabled. But if you think this should be explicitly mentioned, I 
> can mention it.

Just expand you sentence above in the document, and that's perfect.

>> delayed is a transient error response from the next MTA to which the email 
>> must be transferred." should also explicitly refer to the graylisting case 
>> (which also causes often a "reply" message to be delivered before the 
>> original message is).

> Actually, I would rather delete the whole paragraph, as it doesn't add value 
> to the spec (the definition is not used anywhere). Besides greylisting will 
> cause transient errors.

ok.

> Because it is widely used (due to Exchange and some MUAs).

I see the point.

> I don't think it would be a good idea to touch RFC 2156. What do you think is 
> broken in it anyway?

Nothing broken technically. It might just lead some confusion... in 
implementers. But it's a minor point, you can ignore my comment and that's 
fine anyhow.

>> Section 4.5: the text say that in case of mailing lists and aliases the 
>> Header parameters tunnelling this specification extension SHOULD retain the 
>> original priority. What about the many implementations where headers are 
>> completely re-written and many parameters just disappear? Some sentence 
>> should be given about this case, too.
> Can you suggest some specific case? SHOULD is here is exactly to address this 
> kind of case, but I have hard time explaining why it can be violated in 
> general terms.

The SHOULD makes existing ML implementaions compliant :-)

Just add that "in some cases, a ML service might result is dropping the 
tunnelling parameter".

> ? (Which would imply adding a header field for tunneling the priority)

yes.

> If yes, I can clarify that this might be an exception.

ok.

>> ALWAYS happen (different behaviours because different support at various 
>> MX-pointed servers). I'd make the consideration more explicit and suggest a 
>> stronger guidance.

true, not easy... something like:

    If multiple DNS MX records are used to specify multiple servers for a
    domain in section 5 of [RFC5321], it is strongly advised that all of
    them support the MT-PRIORITY extension and handles priorities is
    exactly then same way. If one or more server does behave like that,
    (or even when you cannot fully control the servers behaviour or
    configuration), then it is strongly suggested that none of the servers
    support the MT-PRIORITY extension.
    Otherwise, unexpected differences in message delivery speed or even
    rejections can happen during temporary or permanent failures, which
    users might perceive as serious reliability issues.

this makes the comment stronger... maybe to strong... it's up tp you to 
accept or ignore this stronger version. But also your minimal "strongly 
advised" in the original text is already enough.

>> Appendix A, B, C are very environment specific. Appendix A and C, however, 
>> seem very specific environment related (the NATO messaging military 
>> convetions for "A" and the USA Civil Protecion service for "C"). While "B" 
>> is really global, beacause it maps OSI X.400 service, the other two 
>> appendix seems too environment specific for an international standard RFC 
>> specification. I would suggest handling at least "A' and "C"  not as 
>> appendixes of this document, but as separate short "mapping specification", 
>> also to enable further similar documents to be published/registered more 
>> easily for other environments.
> As per my comment above, most of these will move to a separate specification 
> about tunneling.

ok !

> Alexey

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 25 Apr 2012 13:32:22 +0100

Hi Claudio,
>> started writing some replies, but I only now got around to updating 
>> my copy of the document.
>
Likewise (I've removed part of the exchange where we agree.)
>>> However, it also introduces a concept idea on how to "tunnel" new 
>>> SMTP parameters requests via MTAs which do not support and ignore 
>>> them, embedding them into e-mail Heders fields. In doing this it 
>>> breaks the ideal separation between Envelope (SMTP) and Content 
>>> (Headers and bodyparts) in a different a new way than it was done 
>>> before, because is causes Headers to be able to modify Envelope 
>>> parameters. There is no negative consideration in this, but this 
>>> feature should also be stated more explicitly in the introduction.
>> Right. Based on IETF LC feedback and after talking to Apps AD the 
>> plan is to split the document into 2: one will describe a pure SMTP 
>> extension (with no tunneling) and will be targeted at Proposed 
>> Standard. Another one will be an Experimental document that talks 
>> about tunneling and gatewaying. So I will have more explicit text 
>> about this in the latter document.
> Very good solution!
>>> issues are present. However I suggest yet another turn of 
>>> consideraion for the state iself of the specification: the WG and 
>>> many others propose to go into Standards Track, but in order to do 
>>> this there are at least some more exlicit considerations to clarify 
>>> into the text itself. Also, it is not easy to guess what will be the 
>>> adoption level of this mechanism,
>> That is true.
>> A MTA implementation which accepts the PRIORITY parameter and ignores 
>> it is not particularly harmful. An implementation that treats higher 
>> priority messages as lower priority messages is, well, broken. So I 
>> am not entirely sure what are you thinking about here.
>
> I was considering not specifically the "PRIORITY" case, but in general 
> the idea of the parameters tunneling which is introduced. Of course a 
> mismatched PRIORITY request is not harmful, but if another more 
> essential parameter is tunnelled and lost in transactions (imagine a 
> DSN reuqest for example, if somebody decides to use the mechanism to 
> bypass non DSN conformat e-mail systems...) then it can be harmful. 
> Thus I was considering a possible future scenario, and that's why I 
> was sggesting Experimental for the tunnelling mechanism. As you will 
> split documents, my suggestion is fully accomplished :-)
Great :-).
> I kno people tend to consider e-mail as a real time way to get 
> information to somebody... I do it myself... but, theoretically, we 
> cannot complain if somebody reads the information one week later :-)
True. A delivery of an IM message doesn't mean that either, but I 
digress ;-).
>>> This apparently contradictory point shall be explained better. If 
>>> this specification is going Proposed Standard, it shall be crystal 
>>> clear about these scenarios, because implementers who did not take 
>>> part in the original discussion will implement it, and thus all 
>> etc.), then greylisting should be disabled. But if you think this 
>> should be explicitly mentioned, I can mention it.
>
Done.
> implementers. But it's a minor point, you can ignore my comment and 
> that's fine anyhow.
Ok.
>> Can you suggest some specific case? SHOULD is here is exactly to 
>> address this kind of case, but I have hard time explaining why it can 
>> be violated in general terms.
>
> Just add that "in some cases, a ML service might result is dropping 
> the tunnelling parameter".
I will see where I can add this to the second (Experimental) document.
>>>
>>> Section 9: given the current architecture, I'm very worried this 
>>> will ALWAYS happen (different behaviours because different support 
>>> at various MX-pointed servers). I'd make the consideration more 
>>> explicit and suggest a stronger guidance.
> this makes the comment stronger... maybe to strong... it's up tp you 
> to accept or ignore this stronger version. But also your minimal 
> "strongly advised" in the original text is already enough.
I've used a variant of your text (I've dropped text in (), as I am not 
sure what it is trying to convey and fixed obvious typos).