Message Submission for Mail
draft-gellens-submit-bis-02

[Ballot comment]
Re Harald's DISCUSS, I will clear it if we can change the first sentence of 4.3:

>>> 4.3.  Require Authentication
>>>   
>>>    The MSA MUST issue an error response...

to
    The MSA MUST by default issue an error response...

[Ballot discuss]
There was a last call comment (and Jon's comment) on the use of "Message" as though there is only one type of message on the Internet; this may have been true when this was first published but it is not now.  I would like to see a serious discussion of making the title and the document more specific that it's talking about email.

[Ballot discuss]
1) The "MUST implement" vs "MUST use" discussion from the IETF list needs to have a resolution.
2) Spencer Dawkins' review contains a few things that need cleaning up.

My preferred resolution to the "MUST SMTP-AUTH" issue is to reformulate section 4.3 something like this:

4.3.  Require Authentication
   
    A conforming MSA implementation MUST implement [SMTP-AUTH].
    The RECOMMENDED deployment practice is to configure the MSA so that it
    issues an error response to the MAIL FROM command if the
    session has not been authenticated using [SMTP-AUTH], unless it has
    already independently established authentication or authorization
    (such as being within a protected subnetwork).

My opinion is that the IETF cannot outlaw stupidity in configuration; we should try to say that you can't ship conformant products that REQUIRE you to be stupid.

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

This draft is just a little too rough for publication as Draft
Standard in its current form, although it's close.

Pardon what may be my ownconfusion:

- There are "Note:" paragraphs that I would assume were NOT normative,
  but that contain 2119 normative requirements language ("SHOULD",
  etc.). If they are normative, I'd lose the "Note:", otherwise I'd
  lose the all-caps language.

- In 5.1, I don't get "If the MSA examines or alters the message text
  in way,". At a minimum there seems to be a missing "any",but I
  wasn't sure what my reconstructed sentence was actually saying.I'm
  not sure why "or alters" is necessary (surely one examines messages
  before altering them). Got clue?

Minor nits:

- "SMTP" isn't expanded on first use (I don't believe it's expanded in
  the document). Neither is POP or IMAP4.

- "the prevalenceof malware which turns end-user systems into
  spam-spewing menaces" is wonderfully purple prose (I talk like this,
  too), but not wonderfully clear technical writing. I can't imagine
  many peopleunderstanding this clearly text in 10-20 years. Ata
  minimum, a reference would help.

- There is no reference or explanation for "split-MUA model".

[Ballot discuss]
1) The "MUST implement" vs "MUST use" discussion from the IETF list needs to have a resolution.
2) Spencer Dawkins' review contains a few things that need cleaning up.

[Ballot comment]
The title and abstract of this document use the term 'message' as if it would be immediately understood that this refers to email messages. There are many other sorts of messages used on the Internet today. I think it is important for the title and abstract to identify explicitly the application with which this document is concerned.

[Ballot comment]
Did people notice nanog thread begun by Sean Donelan Feb 15 and continuing through Mar 2:
"Why do so few mail providers support Port 587?"  - praise of this protocol, and questions on
deployment.  Much discussion.

[Ballot comment]
Section 3.3 says:
  >
  > Secure IP [IPSEC] can also be used, and provides additional benefits
  > of protection against eavesdropping and traffic analysis.
  >
  The level of protection against traffic analysis is pretty low.
  While the observer cannot see the email headers or body, the
  observer can see the volume and timing of traffic from each
  client to the MSA.