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

Folks,

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.
Keith
> --- 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 
> document.
>
> 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
>    common.
>
> 4. Section 3, 2nd paragraph, mistates an important concept.  
>
> change
>    Submission typically does entail a relationship between client and server
> to
>    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
>       mechanisms.
>
> 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"
>        relays.
>
> 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"?
>
>    This
>    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
>
>    This
>    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 ---
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf