> > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf