This, I think is the crux of the problem. The statement above appears to
conflate an IP network with an administrative domain, and assumes that
something belongs to one if and only if it belongs to the other.
If I had said "IP" network you'd have a pretty good case. However I meant the
term pretty generically. As you note, the document text uses different words.
In fact that language was carefully chosen. Unfortunately, this thread has
tended toward generalities and imprecise language and I succumbed.
(By the way, thanks for returning to the source material and considering it
specifically.)
o Mail coming from outside an email operator's local environment,
....
Now, connections that come from clients not on my IP network may be from
authorized submission clients which are outside my "local environment".
But, they may also come from clients which are part of my local
environment, but do not happen to be on my local network. I might decide
that a particular client fits that category because of its authenticated
identity, either to SMTP or at some lower layer.
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.
So maybe whether to treat such messages as "submission" or not is not all
that important, especially if it is reasonable under some circumstances to
consider a host not on the local IP network to still be part of the "local
environment"??
Here is the entire text of the recommendations in section 3 of the draft:
Best practices are:
* Operators of MSAs MUST perform authentication during mail submission,
based on an existing relationship with the submitting entity. This requirement
applies to all mail submission mechanisms.
* For email being received from outside their local operational environment,
email service operators MUST distinguish between mail that will be delivered
inside that environment, from mail that is to be relayed back out to the
Internet. This allows the MTA to restrict this operation, preventing the problem
embodied by "open" relays.
* Mail coming from outside an email operator's local environment, and having
a RCPT-TO address that resolves to a destination that is also outside the local
environment, MUST be treated as mail submission, rather than mail relaying.
Hence it must be subjected to mail submission authorization and validation
checks.
* MDAs SHALL NOT accept mail to recipients for which that MDA has no
arrangement to perform delivery.
If you or anyone else has specific changes they are suggesting, I'm at a loss to
guess what.
However, I do have another concern with this requirement, and frankly I
can't remember whether it's been brought up or not. My concern is with the
phrase "resolves to a destination that is also outside the local
environment", and how it interacts with things like forwarding. If the
CMU.EDU mail exchangers receive a message whose RCPT-TO is
jhutz(_at_)cmu(_dot_)edu,
and LDAP says that mail for that address should be delivered to gmail, does
that make it an address that resolves to a destination outside the local
environment? The document is not clear on this, and I'm very concerned
that a wrong answer would result in a lot of incorrectly bounced mail...
unless gmail is part of the local environment for the cmu.edu mail
service, then how could it be interpreted as anything other than
"outside"?
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.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf