[Top] [All Lists]

my Last Call comments on draft-hutzler-spamops-04

2005-06-15 13:56:20

It has been suggested to me via private mail that because my Last Call comments about this document were sent only to IESG, that people might be left with the impression that the disagreement over this document was without substance. For this reason, I've enclosed a copy of my Last Call comments about that document as an attachment to this message.

I recommend that followups be sent to the ietf-smtp(_at_)imc(_dot_)org list, as this seems to be the most appropriate place for the discussion.

--- Begin Message ---

Summary: I believe this document is a good start and has the right intent
and a useful scope, but needs revision (perhaps multiple cycles) before 
publication as BCP.

1. [Nit]  Eric Allman's name is missing in the authors' list at the top of the 

2. Title may be too broad for the intended scope of the document.

3. [Nit] Section 2, next to last paragraph.  Wording is awkward.  Suggest

   These architectural components are often compressed, by having
   the same software do MSA, MTA and MDA functions.  However the
   requirements for each of these components of the architecture are
   becoming more extensive, causing their separation to be increasingly

4. Section 3, 2nd paragraph, mistates an important concept.  

   Submission typically does entail a relationship between client and server
   Submission typically does entail a relationship between the message
   sender and the submission server

5. Section 3, 3rd paragraph

   Specifically, an MSA can choose to reject all postings from MUAs for
   which it has no existing relationship.

change to

   Specifically, an MSA can choose to reject all postings from senders with
   which it has no existing relationship.

Strictly speaking the relationship is with the sender rather than the MUA.  
a single MUA (even a single instance of an MUA) can serve multiple 
senders as long as each sender gives the MUA the appropriate credentials.
(nothing says that the "sender" here has to be a human)

"originator" might be an even better term than "sender".
It might also be worthwhile to define "sender" (or "originator") in section 2.
I am using "sender" more-or-less like it is defined in RFC 822.

6. End of section 3:

The "best practices" bullets seem to worded awkwardly, incorrectly,
and somewhat redundantly.  Here's a stab at better wording:

1st bullet, current text:

   o  Operators of MSAs MUST perform authentication during mail
      submission, based on an existing relationship with the submitting
      entity.  This requirement applies to all mail submission

This seems awkward and a bit unclear.  Suggest change to:

   o  MSAs MUST authenticate (verify the identify of) senders prior to 
       relaying mail received from those senders.  This requirement 
       applies to all mail submission mechanisms, whether or not using SMTP.

however this is slightly problematic.  anonymous mail is valuable in
corner cases. even if few recipients will willingly accept it, some will.
so are the ability to send mail through an MSA not related to the
sender's From address, and the ability to send mail on behalf of
multiple senders.  

so a few things should probably be explicitly discussed somewhere:

1. operators of MSAs SHOULD NOT restrict authorized submitters
    to using particular From addresses, Sender addresses, and/or 
    MAIL FROM addresses.

2. an MSA SHOULD NOT expose the sender's authenticated
    identity in the message.

3. the message SHOULD be traceable by the MSA operator to the
    authenticated identity of the user who sent the message, for a 
    reasonable period of time after the message is sent.   such 
    tracing MAY be based on transaction identifiers stored in 
    Received or other fields in the message.

4. nothing in the current suite of internet mail protocols ensures that 
    any address or authentication token associated with a user is
    uniquely bound to that user, stably bound to that user, or 
    has a long-term association with that user.

(I realize there will probably be some disagreement about both
the scope and the specific content of these recommendations, so for
now I'm only suggesting that these topics probably need to be 
touched on to some level of precsion, and the text above is merely
a starting point)

2nd bullet, current text:

   o  For email being received from outside their local operational
       environment, email service operators MUST distinguish between mail
       that will be delivered inside that environment, from mail that is
       to be relayed back out to the Internet.  This allows the MTA to
       restrict this operation, preventing the problem embodied by "open"

There are several problems with this:

- it confuses "operational environment" with "domain".  mail delivery
  is delegated to one or more incoming MTAs on a per-domain basis.
  there is not necessarily any correspondence between a "domain"
  and an "operating environment" (which I take to be more-or-less
  a portion of the IP network).
- the "distinguishing" is done by an MTA, not by the operator.
- "delivered inside that environment" seems wrong even if you take
   "environment" to be "domain" because it would have operators 
   (or MTAs) reject mail that is being fowarded from an address 
   in a domain for which that MTA is responsible, to an address in
   a domain for which that MTA is not responsible.
- the "distinguishing" needs to be done on a per-recipient basis,
  rather than a per-message basis, since the same message might be
  addressed to multiple addresses, some inside and some outside of
  the domains for which the MTA is authorized to accept incoming mail. 

as a first approximation, change to:

   o Unless the client has authenticated itself to the MTA on behalf of a
      user authorized by the MTA to send mail to other domains,
      the MTA MUST refuse to accept mail for any address in a domain 
      for which the MTA is not authorized to accept incoming mail.

...but probably this needs more work.  In particular, several 
concepts need to be explained - the concept of domain, and the
concept of an MTA being delegated responsibility for acceptance
of mail to addresses in a domain (which is different than the MTA
being listed as an MX for that domain in DNS).  

as a start, I suggest explaining concepts in section 2 like:
"domain" "domain part of a recipient address" and 
"authorized to accept incoming mail for a domain"
and using those terms in section 3.

3rd bullet, current text:
   o  Mail coming from outside an email operator's local environment,
      and having a RCPT-TO address that resolves to a destination that
      is also outside the local environment, MUST be treated as mail
      submission, rather than mail relaying.  Hence it must be subjected
      to mail submission authorization and validation checks.

"resolves to a destination" is problematic because it forbids mail 
forwarding between domains.  rather it should say "RCPT TO address
that specifies a domain for which the MTA is not responsible"

but more generally, I think this is stated incorrectly.  rather than 
saying "if the recipient is nonlocal, you must treat this as submission"
it should say "you must authenticate the sender before accepting
mail to an address in a domain for which you are not responsible".   
part of the problem is that there are other aspects to submission 
besides authorization and validation checks.  for instance, you don't
want to be adding missing header fields or correcting bogus ones
if you're going to reject the message any way - at best this is
wasteful and at worst it destroys valuable evidence.

   o  MDAs SHALL NOT accept mail to recipients for which that MDA has no
      arrangement to perform delivery.

This seems to be redundant with the above text.

7. Section 4, first paragraph:

what is meant by "enforced privacy"?

   requirement creates a challenge for the provider operating the
   network that hosts the MUA.

it seems a bit odd to speak of a network as "hosting" an MUA when the
MUA is on a mobile platform like a laptop that migrates from one network
to another and may be connected to multiple networks concurrently.

I would say

   requirement creates a challenge for the operator of the
   IP network from which the message was submitted.

8. Figure 1, at the end of section 4 is difficult to read.  I can't make
heads or tails of it.

--- End Message ---
<Prev in Thread] Current Thread [Next in Thread>