headers
Bill McQuillan | 12 Jul 2011 00:19
Picon
Favicon

Comments on: draft-melnikov-smtp-priority-02


Comments on: draft-melnikov-smtp-priority-02
SMTP Extension for Message Priorities

Section 2, last paragraph:

Seems to be self-contradictory. Either there are enough resources to 
cause an email to be "ready to be sent" or there aren't!

Section 3, item 5:

This seems to reject that PRIORITY 0 should mean "Normal"

Section 4.2, next to last paragraph:

I believe that the recommendation should be stronger, at least a 
"SHOULD". There must be some cost to using (non-negative) 
PRIORITY. This will guard against abuse. Otherwise, how do you 
deter spammers from always using PRIORITY 99?

Another thing to worry about is that this becomes a new Denial-
of-Service mechanism if not controlled in some way.

Either authentication, SPF (RFC 4408) or similar should be used 
before PRIORITY is allowed.

Section 4.2, last paragraph:

   "priority (both to lower or to upper it)."
(Continue reading)

Permalink | Reply | 12 comments |
headers
Alessandro Vesely | 12 Jul 2011 19:06
Picon
Favicon

More comments on: draft-melnikov-smtp-priority-02


Two comments for section 10, Security Considerations:

First, the phrase

                                     Message Submission Agents can
   implement a policy that only allows authenticated users (or only
   certain authenticated users) to specify message priorities

seems redundant.  Since the message priority can only be specified
during transactions and authentication is implied at such stage, the
parenthesized "only certain" is the working case.

Second, protecting MT-Priority by DKIM-signing it results in broken
signatures in case the priority is altered by a conforming server
before relaying to a non-conforming one.  If it has to be signed, I'd
suggest to revise Section 4.4 so as to never formally alter the field
after it has been signed (presumably by the MSA).  Further MTAs may
treat the message as if it had a lower priority even without altering
the field.

I'd also put a question about section 4.5, Mailing lists and Aliases.
Requiring that the existing priority is retained across expansions
apparently discourages the use of low/negative priority for running
large lists.  Would it make sense, instead, to have a process that
collects a message with, say, priority -3 and 1000 recipients and
re-queues it as 10 conveniently staggered messages with priority -2
and 100 recipients each?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alexey Melnikov | 12 Jul 2011 19:34
Favicon

Re: More comments on: draft-melnikov-smtp-priority-02


Hi Alessandro,
Thank you for your comments.

On 12/07/2011 18:06, Alessandro Vesely wrote:
> Two comments for section 10, Security Considerations:
>
> First, the phrase
>
>                                       Message Submission Agents can
>     implement a policy that only allows authenticated users (or only
>     certain authenticated users) to specify message priorities
>
> seems redundant.  Since the message priority can only be specified
> during transactions and authentication is implied at such stage, the
> parenthesized "only certain" is the working case.
There is no requirement to use SMTP AUTH before using this extension 
(althought it would have been a good idea). But in general, I think 
emphasizing that priority for unauthenticated messages shouldn't be 
trusted is important in the Security Considerations section.
> Second, protecting MT-Priority by DKIM-signing it results in broken
> signatures in case the priority is altered by a conforming server
> before relaying to a non-conforming one.
Right. This is indeed a problem. But I am not yet sure what would be 
more important - preserving the priority value (in case some downstream 
MTA support it), or preserving the DKIM Signature. I need to think a bit 
more about that.
> If it has to be signed, I'd
> suggest to revise Section 4.4 so as to never formally alter the field
> after it has been signed (presumably by the MSA).  Further MTAs may
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alexey Melnikov | 12 Jul 2011 19:55
Favicon

Re: Comments on: draft-melnikov-smtp-priority-02


Hi Bill,
Thank you for the comments.

On 11/07/2011 23:19, Bill McQuillan wrote:
> Comments on: draft-melnikov-smtp-priority-02
> SMTP Extension for Message Priorities
>
>
> Section 2, last paragraph:
>
> Seems to be self-contradictory. Either there are enough resources to
> cause an email to be "ready to be sent" or there aren't!
I will check.
> Section 3, item 5:
>
> This seems to reject that PRIORITY 0 should mean "Normal"
Can you elaborate on why you think so?

> Section 4.2, next to last paragraph:
>
> I believe that the recommendation should be stronger, at least a
> "SHOULD". There must be some cost to using (non-negative)
> PRIORITY. This will guard against abuse. Otherwise, how do you
> deter spammers from always using PRIORITY 99?
This sounds sensible.
> Another thing to worry about is that this becomes a new Denial-
> of-Service mechanism if not controlled in some way.
>
> Either authentication, SPF (RFC 4408) or similar should be used
(Continue reading)

Permalink | Reply | 5 comments |
headers
Bill McQuillan | 13 Jul 2011 09:03
Picon
Favicon

Re: Comments on: draft-melnikov-smtp-priority-02


On Tue, 2011-07-12, Alexey Melnikov wrote:

>> Section 3, item 5:

>> This seems to reject that PRIORITY 0 should mean "Normal"
> Can you elaborate on why you think so?

In this sentence:

> A value of 0 indicates an email from a client/network not
> supporting priorities or intended to be sent to such a server/
> network; this is the same as not specifying the PRIORITY
> parameter.

The possibility that I might want to send a priority 0 (normal)
message FROM a conforming system TO a conforming system seems not
to be considered.

--

-- 
Bill McQuillan <McQuilWP <at> pobox.com>
Permalink | Reply | 4 comments |
headers
Alessandro Vesely | 13 Jul 2011 12:08
Picon
Favicon

Re: More comments on: draft-melnikov-smtp-priority-02


Hi Alexey,

On 12/Jul/11 19:34, Alexey Melnikov wrote:
> On 12/07/2011 18:06, Alessandro Vesely wrote:
>> Two comments for section 10, Security Considerations:
>>
>> First, the phrase
>>
>>                                       Message Submission Agents can
>>     implement a policy that only allows authenticated users (or only
>>     certain authenticated users) to specify message priorities
>>
>> seems redundant.  Since the message priority can only be specified
>> during transactions and authentication is implied at such stage, the
>> parenthesized "only certain" is the working case.
>
> There is no requirement to use SMTP AUTH before using this extension

(I meant before using MSA)

> (althought it would have been a good idea). But in general, I think
> emphasizing that priority for unauthenticated messages shouldn't be
> trusted is important in the Security Considerations section.

Yes, that looks right.  Then something like

   Message Submission Agents /and SMTP servers/ can implement a...

>> Second, protecting MT-Priority by DKIM-signing it results in broken
(Continue reading)

Permalink | Reply | 1 comment |
headers
ken carlberg | 13 Jul 2011 13:48
Picon

Re: Comments on: draft-melnikov-smtp-priority-02


On Jul 13, 2011, at 3:03 AM, Bill McQuillan wrote:

>> A value of 0 indicates an email from a client/network not
>> supporting priorities or intended to be sent to such a server/
>> network; this is the same as not specifying the PRIORITY
>> parameter.
> 
> The possibility that I might want to send a priority 0 (normal)
> message FROM a conforming system TO a conforming system seems not
> to be considered.

ok.  It will be easy to add text and stating up front that a value of zero, by default, indicates "normal".  And
then add the existing caveats.  And by "normal", I assume that we are in agreement that this describes the
best effort service model that exists today as if the proposed extension never existed.

-ken
Permalink | Reply | 3 comments |
headers
ken carlberg | 13 Jul 2011 14:17
Picon

Re: More comments on: draft-melnikov-smtp-priority-02


Alessandro,

>>> Would it make sense, instead, to have a process that collects a
>>> message with, say, priority -3 and 1000 recipients and re-queues
>>> it as 10 conveniently staggered messages with priority -2 and 100
>>> recipients each?
>> 
>> I don't think this is prohibited, but can you elaborate on why this
>> would be desirable? For example, while not keep the priority -3 when
>> generating multiple messages?

Given your description above, my initial reaction would be to not allow (or just to heavily discourage) the
example that you give above.  I still need to think about this some more, but I would have a preference to
maintain the consistency of the value of the signaled priority.  On the other hand, if there was a need for a
local decision of how to service the set of prioritized messages, then perhaps weights could be
set/changed in terms of how to service queues.

> Thank you for considering this problem.  I've seen Bill's observation
> on possible starvation at negative priorities, and wandered whether
> PRIORITY could solve delayed relaying in general, possibly as a
> secondary target.
> 
> Of course, there are myriads of full blown solutions for large scale
> mailing.  Still, some users prefer regular multi-recipient messages,
> even at the costs of breaking their recipient list in chunks of
> acceptable size, and managing bounces by themselves.  As a side
> effect, their behavior may delay normal messages that get queued
> behind the bunch.  For a local solution, a server may handle such
> messages using a specific algorithm for scheduling retries, and do a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Murray S. Kucherawy | 14 Jul 2011 05:45

RE: More comments on: draft-melnikov-smtp-priority-02


> -----Original Message-----
> From: owner-ietf-smtp <at> mail.imc.org [mailto:owner-ietf-smtp <at> mail.imc.org] On Behalf Of Alexey Melnikov
> Sent: Tuesday, July 12, 2011 10:34 AM
> To: Alessandro Vesely
> Cc: carlberg <at> g11.org.uk; SMTP Discussion
> Subject: Re: More comments on: draft-melnikov-smtp-priority-02
> 
> > Second, protecting MT-Priority by DKIM-signing it results in broken
> > signatures in case the priority is altered by a conforming server
> > before relaying to a non-conforming one.
> 
> Right. This is indeed a problem. But I am not yet sure what would be
> more important - preserving the priority value (in case some downstream
> MTA support it), or preserving the DKIM Signature. I need to think a
> bit more about that.

If the MTA is DKIM-aware, it could detect whether MT-Priority is signed and then decide not to change it.  But
that seems pretty complicated.

I think in this case it should simply re-sign the message after alteration.

You could also discourage signing of it, citing this example.
Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 22 Jul 2011 21:53
Favicon

Re: Comments on: draft-melnikov-smtp-priority-02


ken carlberg wrote:
> On Jul 13, 2011, at 3:03 AM, Bill McQuillan wrote:
>   
>>> A value of 0 indicates an email from a client/network not
>>> supporting priorities or intended to be sent to such a server/
>>> network; this is the same as not specifying the PRIORITY
>>> parameter.
>>>       
>> The possibility that I might want to send a priority 0 (normal)
>> message FROM a conforming system TO a conforming system seems not
>> to be considered.
>>     
> ok.  It will be easy to add text and stating up front that a value of zero, by default, indicates "normal".  And
then add the existing caveats.  And by "normal", I assume that we are in agreement that this describes the
best effort service model that exists today as if the proposed extension never existed.
>   
I've tried to clarify this by removing "or intended to be sent", as this 
is not relevant here. My current text reads:

      A value of 0 indicates an email from a client/network not
      supporting priorities, which is the same as not specifying the 
PRIORITY parameter,
      i.e. this value will cause the standard SMTP behaviour in absence 
of this extension.

Is this better?
Permalink | Reply | 2 comments |

Gmane