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

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2005 20:15:10 -0400

>>>  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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Thu, 9 Jun 2005 17:38:59 -0700

> >  different from the document being "incorrect".
> >

Ok.  Please explain precisely what text in the draft is "incorrect" and what is 
"incorrect" about it.  

What you wrote means that you are asserting that we did not mean treat as 
submission.  And I'll just bet that's not what you actually meant.

>  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."

> >  Again, I believe you are confusing what your own views and preferences
> >  are, with some sort of independent, objective reality.
> >

Yes, you could.  But that would be incorrect.

> >  "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.
> >
>  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.  

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".

>  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,"

Whereas references to the services on different ports is... gosh.  By port 
number.

If you want text changed, then please suggest specific changes.

>  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.

>  an MTA as a submission has never been well defined".

Given that section 3 discussion the construct extensively, then I cannot 
guess what more you are looking for.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2005 22:04:06 -0400

> Ok.  Please explain precisely what text in the draft is "incorrect"  

You have been sent a copy of my last call comments that I sent to  
IESG.  If you need clarification, please let me know.

>>> was wrong and that there is not a fourth case.  If you feel  
>>> otherwise, please provide detail.
>>>

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.

>>> preferences

> Yes, you could.  But that would be incorrect.

You are entitled to your opinion :)

>>> might be

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.

> the MSA is on, then all the users are "outside the network".

or maybe there is no "the network".

>>> step.  It quite  carefully distinguishes between the two ports  
>>> through which  submission is currently done.
>>>
> 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.

> to me what specific references it makes and what specific changes  

see my message to IESG for other suggestions.

Keith