The good part of this requirement seems to be to subject such mail to
authorization (and in many cases authentication). However I think
that saying mail must be treated as submission rather than relaying
may have effects significantly beyond authorization/authentication.
For example MSAs are given significant freedom to modify submitted
That's right.
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.
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.
Also, mail relaying
and submission have different protocols defined by different
specifications. For the most part these protocols are interoperable
but the requirement seems overly strict given this situation.
SUBMISSION is relatively recent and it's use is still only for a portion
of the posting traffic on the Internet. From a practical standpoint, port
25 is still heavily used; so that the two types of traffic are still
frequently multiplexed over 25. Hence any BCP concerning initial posting
needs to cover both ports.
There seems to be some ambiguity between treating an incoming
message as a submission and using the SUBMISSION protocol.
It seems prudent to clearly distinguish the two. And since treating
an incoming message as a submission has never been well-defined,
perhaps a different way of describing what an MTA should do when
an unauthenticted sender tries to send to a recipient not in a domain
for which the MTA is authorized to accept incoming mail, would be
appropriate.
bottom line: the spec as written is poorly worded and needs
significant revision. I'm sending comments to IESG separately.
(and yes, I found the same problem that Sam did, before I read
his message)
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf