The implications you are drawing are exactly what is intended.
When the
document said "treat as a submission" it meant exactly that.
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.
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.
This is wrong. "outside the network" is irrelevant. What
matters is
whether you are authorized to use that MTA to submit messages to
recipients not in the domain(s) for which that MTA is authorized
to accept
incoming mail.
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.
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.
"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. This is a less-than-general
perspective, as there are MSAs that are independent of IP networks,
and IP networks may wish to outsource mail service. Since the email
architecture delegates MTA authority on a per-domain basis (via DNS
and MX records), rather than by IP address blocks, the document
would be more broadly applicable if it were rewritten to separate the
concept of "operating environment" from the concept of domain.
If you're going to make a document that is narrowly scoped than that,
you should at least state the scope.
Of course, if a user's identity is reliably known from his source IP
address, combined with the knowledge an operator has that its network
is adequately protected against source IP spoofing, this might
reasonably be considered sufficient authentication for that user.
But this should probably be stated explicitly and precisely rather
than buried in the undefined concept of operating environment. And
the question of whether a user should be able to use a particular
server for message submission, or whether a message is treated as a
submission, probably shouldn't depend on _how_ a user has
authenticated - whether by passwords over TLS or TLS client certs or
by PPPoE to the provider's network (as indicated by source IP
address) - so long as the user's identity is reliably known.
There seems to be some ambiguity between treating an incoming
message as a submission and using the SUBMISSION protocol.
Well, I don't see the ambiguity, but I do see the confusion.
Submission is a hand-off from the From/Sender user realm to the
mail handling
service. SUBMISSION is a particular port and service for doing
submissions.
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.
Indeed, it appears that the document uses several vague terms without
bothering to define them.
It seems prudent to clearly distinguish the two. And since treating
an incoming message as a submission has never been well-defined,
the term "incoming" is what causes the problem here. For every
server, every
message that it receives is "incoming". that is true for msa's as
well as mtas.
agreed.
however i suspect what you mean, here, is 'coming from outside the
network'.
since you earlier said that it is irrelevant, i'm not sure what
your point is,
here.
no, that's not what I meant. I meant "treating a message received by
an MTA as a submission has never been well defined".
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf