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

[Jeffrey Hutzelman <jhutz at cmu.edu>]

On Friday, June 10, 2005 12:55:27 AM -0700 Dave Crocker <dhc2 at dcrocker.net> 
wrote:


> If my use of "network" on this thread were meant as something different
> from  "local environment" in the draft, then combinatorial concern you
> are raising  would indeed need attention.  And I wish I believed that my
> use of the word were  the cause of the problem on this thread.

It was for me.  Reading the earlier messages, it seemed to me that the 
specified behavior was broken.  Then I went back and read the original 
text, and saw that it said "local environment" and nothing about "network", 
and it suddenly didn't seem so broken any more.


> If you or anyone else has specific changes they are suggesting, I'm at a
> loss to  guess what.

I'm not suggesting any change.  I initially had the same concern as Sam, 
that there was a requirement to treat things as submission that really 
weren't.  But given a reasonable interpretation of "local environment" 
(i.e. one that does not assume it always means "local IP network"), I've 
managed to convince myself that there aren't any cases left where it 
matters.  So if the experts don't think this is a problem, then neither do 
I.



> the trick is to be careful in deciding when the evaluation is being
> done: it is evaluated at delivery time, not at the time of acceptance
> into the cmu.edu mail service.
>
> And by the way, if folks want to get into this sort of detail about the
> variations in email handling, I ask that they first make sure they are
> familiar with:
>
>  <http://bbiw.net/specifications/draft-crocker-email-arch-04.html>.
>
> It has gone through extensive development, specifically because these
> kinds of variations turned out to take quite a bit more thought and
> explanation that had originally been obvious.  The community does not
> have consistent, common language and definitions.  Until we do, debates
> about particular variations are sure to continue to get caught in
> unstated assumptions.

Indeed.  The answer to my concern appears to lie in the subtle but 
significant semantic distinction between Relaying and Aliasing, which I 
didn't understand before reading your architecture document.  Having done 
so, I can withdraw my comment on the "resolves to" phrasing, and replace it 
with a different one:

Maybe the spamops document needs a reference to the email-arch document?


-- Jeff

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf