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@xxxxxxx list, as
this seems to be the most appropriate place for the discussion.
Keith
--- Begin Message ---
- To: iesg@xxxxxxxx
- Subject: Re: Last Call: 'Email Submission Between Independent Networks' to BCP
- From: Keith Moore <moore@xxxxxxxxxx>
- Date: Thu, 9 Jun 2005 17:45:18 -0400
- Cc: moore@xxxxxxxxxx
- In-reply-to: <E1DeCVx-0007L2-L3@newodin.ietf.org>
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf