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

> > > >  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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf