this is a german Web-Mirror of MHONARC.ORG powered by Domainunion AG

ietf-smtp
[Top] [All Lists]

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

2011-07-12 13:09:06

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
before PRIORITY is allowed.
I will try to make the current text stronger on that.
Section 4.2, last paragraph:

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

  Perhaps:

    "priority (both to lower or to raise it)."
Ok.
Section 4.3, Item 1:

I think that this means that a message received with with NO
priority indication (thus "normal") MUST be relayed with a
PRIORITY 0 parameter. This seems overly stringent.
This is necessary if there is a PRIORITY parameter and an MT-Priority header field value and they don't agree for whatever reasons.
Also, does this paragrah mean that if an MTA only implements the
suggested 6 priority levels, a message received with, e.g.,
PRIORITY 93 MUST be relayed with a PRIORITY 93 parameter? This
seems reasonable, but the text is not quite clear.
Right, that was the intent. I will clarify.
Section 4.6, item 2:

What is needed is some sort of meaning specified for the 199
possible values that does not require reference to other mutually
inconsistent priority schemes.

E.g., MMHS: -20 = routine, 0 = priority. Really?
Right, I've messed up with the mapping. The meaning of priority 0 as "normal" was added later... I will fix.
So, does "PRIORITY 50" mean:

    "You should probably read this first"
or:
    "CAP'N SHE'S GONNA BLOW!"?


Section 5.1:

Since the vast majority of messages will either be marked as
"PRIORITY 0" or presumed to be priority 0, is there any mechanism
to prevent starvation for those messages marked at a negative
priority? Note that for a high volume MTA there would likely
always be SOME priority 0 messages in the queue which would
preclude sending ANY messages at a lower priority.
There is no such mechanism for 5.1. 5.2 will work better in this respect.
Section 5.1, paragraph 3:

The first sentence is unclear. It seems to have *emails* being
forbidden to initiate tranactions. I would expect MTAs to be the
object of any restrictions.
Good point.