Sam is correct here - the text as written is incorrect, even if it
accurately reflects the authors' intent.
You mean that you disagree with the authors' intent. That is quite
different from the document being "incorrect".
I meant what I said. You may infer that it is my opinion, and take
that for what you think it's worth.
Ok. Please explain precisely what text in the draft is "incorrect"
and what is
"incorrect" about it.
You have been sent a copy of my last call comments that I sent to
IESG. If you need clarification, please let me know.
I gave a case analysis for 3 conditions. I believe none of them
was wrong and that there is not a fourth case. If you feel
otherwise, please provide detail.
I didn't see a clear breakdown of those cases.
A Friday, 5:27pm posting from me:
"In other words, if you are coming from outside the network, you do
not get to
"relay" through the network. You can post/submit from within, you
can deliver
into the net or you can post/submit from outside."
okay, fine. first, it's less than general to assume that there is a
network that is "the network" associated with the MSA. second,
depending on source IP address for authentication or an indication of
trustworthiness is of limited applicability - though there may be
cases where it's reasonable to do, it's not reasonable to do in
general, and it's not reasonable to expect these cases to apply to
all MTAs. and in particular I don't think it's reasonable to treat a
source IP address as an indication of trustworthiness unless you
reliably know _who_ is associated with that source IP address, and
that imposes several constraints on how you operate your network that
are not generally met by IP networks. (if memory serves, we don't
usually consider authentication by source address to be "BCP"
material, though I believe that it may be reasonable to do so in this
case as long as appropriate constraints are identified)
finally, I believe it is simpler and clearer to treat the case where
the client authenticates to the MSA/MTA via SMTP AUTH and the case
where the client authenticates to the MSA/MTA via source IP address
as the same case. In effect, either (a) you're both authenticated
(by any of a variety of means) and authorized to relay mail to
domains (not networks) other than those for which the MTA is
authorized to accept mail for, or (b) you're not able to relay mail
to domains other than those for which the MTA is authorized to accept
mail.
if there's a reason for having the MTA treat clients that are
authenticated via source IP address differently from clients that are
authenticated by other means, I haven't seen it.
Again, I believe you are confusing what your own views and
preferences
are, with some sort of independent, objective reality.
I could make the same claim about what you seem to be doing.
Yes, you could. But that would be incorrect.
You are entitled to your opinion :)
"Outside the network" is exactly what we felt was relevant. It
might be
dandy to phrase this as some more generic issue, but since this
is an
operations document, for consumption by operations people, it is
phrased
in a way that is useful to THEIR perspective.
This perspective is specific to MSAs that are operated by IP
networks
for the customers of those IP networks.
Actually it is not. It specifies a topological distinction that is
quite
straightforward and has nothing to do with any business
relationship, per se.
I could try to nail down the details, but I suspect it's a rathole.
I think the burden is on you to explain why "the network" (which I
take to be the IP source address) is _in general_ relevant to whether
an MTA/MSA should accept mail for relaying to domains other than
those it is authorized to accept incoming mail for.
If all of an MSA's users access the MSA from networks other than
the one that
the MSA is on, then all the users are "outside the network".
or maybe there is no "the network".
The document uses the term 'submission' to refer to the hand-off
step. It quite carefully distinguishes between the two ports
through which submission is currently done.
I don't see any effort to distinguish the two, say in section 2.
Section 2, Terminology.
Definition of the word submission:
"At the origination end, an MUA works on behalf of end users to
create a message
and perform initial "submission" into the transmission infrastructure,
that's not a definition, that's a use of the word.
here's my concern about treating this concept in a fuzzy fashion -
while it's all well and good to say MTAs should not accept nonlocal
mail from unauthenticated users (i.e. no third party relaying), we
really don't want to encourage MTAs to perform the kinds of munging
that MSAs are allowed to perform. so it's far better to say "MTAs
should not accept mail to nonlocal users from unauthenticated
clients" (perhaps in more detail) than to say "MTAs must treat mail
from nonlocal and unauthenticated users as submissions". the first
is much more precise.
in general the OPES principles apply here - any modifications made to
a message in transit (other than normal received fields) need to be
authorized by either the originator or recipient. granted that many
such modifications are already existing practice, but they're not
Best Current Practice, and we shouldn't bless them as such by
authorizing them in this document.
but as I write this I realize there's another issue lurking - that of
"validation checks". because I'm guessing that some of those
"validation checks" might be on MAIL FROM and/or From address to make
sure that they correspond with the authenticated identity of the
submitter. if that's what is intended, this is an incompatible
change and is definitely something that should not be part of a BCP.
if nothing else, "validation checks" seems like another vague term
that is used without being defined.
Indeed, it appears that the document uses several vague terms
without
bothering to define them.
Speaking of vagueness, please review your sentence, directly above,
and explain
to me what specific references it makes and what specific changes
it calls for.
see my message to IESG for other suggestions.
Keith
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf