Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt

From: Alexey Melnikov <[email-masked]>
Date: Fri, 03 Nov 2006 12:01:33 +0000

Randall Gellens wrote:

> At 7:53 PM +0100 10/25/06, Alexey Melnikov wrote:
>
>>  Randall Gellens wrote:
>>
>>>  A few comments on this version:
>>>
>>>  ----------------------------------------
>>>  (1) Please explicitly state that servers MUST support [message 
>>> submission] on port 587.  Also, Lemonade clients MUST use port 587 
>>> by default.  (I proposed this on the list back in March and saw some 
>>> agreement and no disagreement.)  The current document says that it 
>>> "assumes RFC 4409" but I think it would be helpful to be more clear 
>>> about this.
>>
>> Tell me which section should say that.
>
> I was thinking either a short new paragraph at the end of either 
> Section 3.5 "Normative statements related to forward without 
> download", or, if you prefer, Section 6 "Additional requirements on 
> MUAs".

IMHO, section number 3.5 is not the right place for this.

I've added the following sentence to section 6:

    By default LEMONADE compliant clients MUST use port 587 for message 
submission.

And I've also added the following sentence to the subsequent section 
(section 6 only talks about MUAs) "Summary of the required IMAP and SMTP 
extensions":

 Note that LEMONADE compliant servers MUST support message submission on 
port 587.

>>>  ----------------------------------------
>>>  (3) In Section "4.3.  Message size declaration", the text:
>>>     LEMONADE compliant mail submission servers MUST resolve all BURL
>>>     parts before enforcing a message size limit.
>>>
>>>  Requires the servers to expand all BURL parts, even if the message 
>>> already exceeds the message size limit.  A while back I suggested 
>>> saying "Servers MUST NOT consider a message's size to be acceptable 
>>> if it has not expanded all BURL parts."  I'm not wedded to that 
>>> phrasing, but I do think we should allow servers to reject messages 
>>> before expanding everything.
>>
>> I am not exactly happy with your replacement text, this might be too 
>> subtle for people to notice. I need to think about better alternatives.
>
> If you'd like to make the situation very explicit and clear, how about:

This is much better because it gives explanation for the requirement. 
Thanks!
Some minor comments below.

> Interoperability problems and user confusion would result from 
> submission servers accepting a message with a 2xx result code, and 
> then, after expanding BURL parts, determining that the final size of 
> the message is too large.

IMHO, this can still happen if the message exceeds per user SMTP quota, 
which can be lower than the advertised SIZE limit.
But I am not sure if there is any point of tweaking the text any further 
in order to clarify "too large".

> In such cases, the submission server would then generate an DSN 
> bounce, which the client would need to receive and process during some 
> subsequent mail check.  Correct matching of the DSN to the original 
> message is difficult, subject to unpredictable delay, and much user 
> annoyance.  If the bounce contains the expanded BURL parts, its size 
> could make it difficult for the client to receive it.  Therefore, 
> servers MUST NOT consider a message's size to be acceptable before all 
> of its BURL parts have not been expanded.

"have been expanded"?

>   Servers MAY reject a message as being too large before expanding all 
> BURL parts, and it is RECOMMENDED that servers check the message's 
> size after expanding each BURL, to guard against denial of service 
> attacks.

Ok, I've added this text, replacing "have not been expanded" with "have 
been expanded" above.
I've also replaced "it's" with "its".

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Randall Gellens <[email-masked]>
Date: Sun, 5 Nov 2006 16:35:46 -0800

At 12:01 PM +0000 11/3/06, Alexey Melnikov wrote:

>     By default LEMONADE compliant clients MUST use port 587 for 
> message submission.
>
>  And I've also added the following sentence to the subsequent 
> section (section 6 only talks about MUAs) "Summary of the required 
> IMAP and SMTP extensions":
>
>  Note that LEMONADE compliant servers MUST support message 
> submission on port 587.

Excellent.  Thank you.

>  IMHO, this can still happen if the message exceeds per user SMTP 
> quota, which can be lower than the advertised SIZE limit.
>  But I am not sure if there is any point of tweaking the text any 
> further in order to clarify "too large".

I agree on both points (it can still happen, but there is no benefit 
from further tweaking the text).

>> bounce, which the client would need to receive and process during 
>> some subsequent mail check.  Correct matching of the DSN to the 
>> original message is difficult, subject to unpredictable delay, and 
>> much user annoyance.  If the bounce contains the expanded BURL 
>> parts, its size could make it difficult for the client to receive 
>> it.  Therefore, servers MUST NOT consider a message's size to be 
>> acceptable before all of its BURL parts have not been expanded.
>
>  "have been expanded"?

You are correct of course (I originally wrote "if ... not been 
expanded" and then tried to change it to "before ... been expanded" 
but didn't complete the edit).

>  Ok, I've added this text, replacing "have not been expanded" with 
> "have been expanded" above.

Thank you.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Not a shred of evidence exists in favor of the idea that
life is serious.                          --Brendan Gill

---

From: <[email-masked]>
Date: Mon, 6 Nov 2006 10:35:47 +0200

Hi all,
I am not sure about this statement:

>    By default LEMONADE compliant clients MUST use port 587 
>for message submission.

By default... MUST...
Should we describe what MUST happen in a non-default case?

---

From: <[email-masked]>
Date: Mon, 6 Nov 2006 17:32:02 +0200

Hi Randalll,

>I don't think we need to say any more.  The client is free to 
>use several approaches, including falling back to port 25 if 
>port 587 doesn't work.  By mandating that servers support port 
>587, and that clients use port 587 as the default, we provide 
>a basis for interoperability.

If we mandate 587 for servers, what is the benefit of specifying
anything for the client?
I mean 587 is always going to be available on every single server
(because it is mandatory), but it will be there also when the server
provides access on other ports as well (again, because 587 is mandatory)
- so why specify anything for the client? It should be obvious from the
server requirement.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 6 Nov 2006 07:21:13 -0800

>  Hi all,

Hi Zoltan,

>  Should we describe what MUST happen in a non-default case?

I don't think we need to say any more.  The client is free to use 
several approaches, including falling back to port 25 if port 587 
doesn't work.  By mandating that servers support port 587, and that 
clients use port 587 as the default, we provide a basis for 
interoperability.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Waiter: "Tea or coffee, gentlemen?"
1st customer: "I'll have tea."
2nd customer: "Me, too -- and be sure the glass is clean!"
        (Waiter exits, returns)
Waiter: "Two teas.  Which one asked for the clean glass?"

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 6 Nov 2006 16:46:11 +0100

[email-masked] writes:
> provides access on other ports as well (again, because 587 is 
> mandatory) - so why specify anything for the client? It should be 
> obvious from the server requirement.

Almost. There's a lot of client code today that uses port 25 by default. 
The document makes a requirement on that code, "change the default to 
587". It's friendly and helpful to say so directly, rather than 
expecting those client authors to care about the the server requirement 
list.

As it is, a client is compliant when it does everything the document 
says a "client MUST" or "client SHOULD" do.

Arnt

---

From: Ned Freed <[email-masked]>
Date: Mon, 06 Nov 2006 08:25:33 -0800 (PST)

> - so why specify anything for the client? It should be obvious from the

Without a client mandate there's nothing to prevent clients from failing to
implement support for port 587 and still claiming compliance with the
specification. If past experience is any indication, this is a serious concern
if we want support for submit to deploy as widely as possible.

It should also be noted that mandating support is different from mandating
actual use.

				Ned

---

From: Randall Gellens <[email-masked]>
Date: Mon, 6 Nov 2006 09:39:34 -0800

Hi Zoltan,

>  - so why specify anything for the client? It should be obvious from the

It's not as obvious as it needs to be, given the practice of using 
port 25 for both submission and relay.  By making a clear and simple 
statement that servers MUST support port 587, and clients MUST use 
port 587 by default, we make guarantee interoperability.

-------------- Randomly-selected tag: ---------------
We adore chaos because we love to produce order.
                                  --M. C. Escher

---

From: <[email-masked]>
Date: Tue, 7 Nov 2006 13:34:01 +0200

Hi Ned,

>> mandatory)
>> - so why specify anything for the client? It should be obvious from 
>> the server requirement.
>
>Without a client mandate there's nothing to prevent clients 
>from failing to implement support for port 587 and still 
>claiming compliance with the specification. If past experience 
>is any indication, this is a serious concern if we want 
>support for submit to deploy as widely as possible.
>
>It should also be noted that mandating support is different 
>from mandating actual use.

Exactly. So why mandate support for something that might not be used at
all? How are You going to IOP test this (I support something that I do
not ever use)?
It's kind of like the seatbelt - most people use it only when they find
it appropriate according to their current environment (e.g highways).
But, for example In Finland there are scenarios when it is actually
forbidden to use the seatbelts.

---

From: <[email-masked]>
Date: Tue, 7 Nov 2006 13:39:08 +0200

Hi Arnt and Randall,

>It's not as obvious as it needs to be, given the practice of 
>using port 25 for both submission and relay.  By making a 
>clear and simple statement that servers MUST support port 587, 
>and clients MUST use port 587 by default, we make guarantee 
>interoperability.

I though the deployment considerations draft was pretty clear on port 25
being obsolete and using port 587 instead. I think that's the closest we
can get when we attept to clarify this issue. Why not reference it
instead?

---

From: Mark Crispin <[email-masked]>
Date: Tue, 7 Nov 2006 06:00:09 -0800 (PST)

> all? How are You going to IOP test this (I support something that I do

Spammers and viruses are doing an excellent job of abolishing SMTP-only 
clients.

At an increasing number of sites, use of 587 is is mandatory.  Clients 
that do not support 587 simply will not work.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 7 Nov 2006 06:03:34 -0800 (PST)

> that do not support 587 simply will not work.

As a follow-up; I simply can not believe that there is any debate or 
dispute about the need to require 587.  SMTP is dead for message 
submission, long live SUBMISSION.

How about being blunt, and state "support for port 587 (SUBMISSION) is 
mandatory.  Any implementation that does not support (and use) port 587 
is, by definition of this standard, a non-compliant piece of garbage whose 
vendor deserves public humiliation." ???  ;-)

With tongue firmly in cheek,

-- Mark --

http://panda.com/mrc

---

From: <[email-masked]>
Date: Tue, 7 Nov 2006 17:13:26 +0200

Hi Mark,

>As a follow-up; I simply can not believe that there is any 
>debate or dispute about the need to require 587.  SMTP is dead 
>for message submission, long live SUBMISSION.
>
>How about being blunt, and state "support for port 587 
>(SUBMISSION) is mandatory.  Any implementation that does not 
>support (and use) port 587 is, by definition of this standard, 
>a non-compliant piece of garbage whose vendor deserves public 
>humiliation." ???  ;-)

I have no problem with stating this - since it removes the in-my-opinion
not-so-good by-default-MUST.

---

From: Ned Freed <[email-masked]>
Date: Tue, 07 Nov 2006 09:43:14 -0800 (PST)

> all?

So it can be used if it is needed.

> How are You going to IOP test this (I support something that I do
> not ever use)?

We take stuff to test events all the time prior to it being used in the field.
Perhaps there's something odd about the OMA process that somehow prevents
testing stuff that isn't in use, but if so that's a bug in the OMA IOP process.

> forbidden to use the seatbelts.

Whatever. The bottom line is that the IETF mandates implementation but not use
of important features all the time and there's a strong and broad consensus
that this is an effective way to get stuff to deploy.

During the discussions leading up to creation of the Danvers Doctrine (which
basically says that it is a good thing to require implementation of strong
crypto even if there are no requirements that it actually be used) all of the
arguments you've given here were raised, and many others as well. The IETF
pushed forward with the requirements anyway, and in hindsight it if pretty
clear that this was the right choice and thw world is a better place for our
having done so. I don't think the case for this requirement is quite as strong,
but it is plenty strong enough.

				Ned

---

From: Randall Gellens <[email-masked]>
Date: Tue, 7 Nov 2006 14:00:12 -0800

>  can get when we attept to clarify this issue. Why not reference it

I don't see any benefit from having the Profile document reference 
the Deployments document for the purpose of mandating support for 
port 587.  Why not just say "Clients MUST use port 587 by default"?

The "by default" means "when opening a connection to the submission 
server, clients MUST attempt to open port 587 on the submission 
server.  Clients MUST NOT try a different port unless this attempt 
fails, or the client has been explicitly configured to use a 
different port."
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Ever notice that people who are late are much jollier
than the people who have to wait for them?

---

From: <[email-masked]>
Date: Wed, 8 Nov 2006 10:24:15 +0200

Hi Randall,

>The "by default" means "when opening a connection to the 
>submission server, clients MUST attempt to open port 587 on 
>the submission server.  Clients MUST NOT try a different port 
>unless this attempt fails, or the client has been explicitly 
>configured to use a different port."

Could we add this then?

---

From: Randall Gellens <[email-masked]>
Date: Wed, 8 Nov 2006 09:56:35 -0800

>>configured to use a different port."

Personally, I think "by default" covers it, but if you feel that the 
broader audience for the lemonade Profile document would benefit from 
more clarification, I'm OK with adding the additional text.  Let me 
try to improve the wording a little, though:

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

When opening a connection to the submission server, clients MUST do 
so using port 587 unless explicitly configured to use a different 
port.  If the TCP connection to the submission server fails to open 
using port 587, the client MAY then immediately retry using a 
different port, such as 25.  See [Submit] for information on why 
using port 25 is likely to fail depending on the current location of 
the client, and may result in a failure code during the SMTP 
transaction.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
A successful tool is used to do something undreamed of by its author.
                                                           --Johnson

---

From: <[email-masked]>
Date: Thu, 9 Nov 2006 10:22:11 +0200

Hi Randall,
Your latest proposal -

>When opening a connection to the submission server, clients 
>MUST do so using port 587 unless explicitly configured to use 
>a different port.  If the TCP connection to the submission 
>server fails to open using port 587, the client MAY then 
>immediately retry using a different port, such as 25.  See 
>[Submit] for information on why using port 25 is likely to 
>fail depending on the current location of the client, and may 
>result in a failure code during the SMTP transaction.
>--

 - covers all of my worries, I hope we can add this to the document.
Thank You.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 13 Nov 2006 03:50:19 -0800

Randall Gellens wrote:

> When opening a connection to the submission server, clients MUST do so 
> using port 587 unless explicitly configured to use a different port.  
> If the TCP connection to the submission server fails to open using 
> port 587, the client MAY then immediately retry using a different 
> port, such as 25.  See [Submit] for information on why using port 25 
> is likely to fail depending on the current location of the client, and 
> may result in a failure code during the SMTP transaction.

I like your text and added it to my copy of the document. But what is 
"may result in a failure code during the SMTP transaction"? Should we 
just say "may result in a failure of the SMTP transaction"?

---

From: Randall Gellens <[email-masked]>
Date: Fri, 17 Nov 2006 12:45:02 -0800

At 3:50 AM -0800 11/13/06, Alexey Melnikov wrote:

>  Randall Gellens wrote:
>
>>  When opening a connection to the submission server, clients MUST 
>> do so using port 587 unless explicitly configured to use a 
>> different port.  If the TCP connection to the submission server 
>> fails to open using port 587, the client MAY then immediately 
>> retry using a different port, such as 25.  See [Submit] for 
>> information on why using port 25 is likely to fail depending on 
>> the current location of the client, and may result in a failure 
>> code during the SMTP transaction.
>
>  I like your text and added it to my copy of the document. But what 
> is "may result in a failure code during the SMTP transaction"? 
> Should we just say "may result in a failure of the SMTP 
> transaction"?

"likely to fail depending on the current location of the client" is a 
reference to port 25 blocking and other modern differences in port 25 
behavior depending on the current IP address of the client. 
Especially with mobile clients, this is a big concern.

"may result in a failure code during the SMTP transaction" means the 
same as "a failure of the SMTP transaction" but was an attempt to be 
more specific as to how it would fail.  But I'm fine with using your 
phrase.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
They say that 90 per cent of TV is junk.  But 90 per cent
of *everything* is junk.
      --Gene Roddenberry, interview in TV Guide, Apr. 27, 1974
      (quoting Sturgeon's Revelation: "Ninety percent of
      everything is crap.")