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

[Alexey Melnikov <[e-mail]>]

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