Re: Last Call: 'Email Submission Between Independent Networks' to BCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]