Sam, > First, in section 5, please do not list cram-md5 as a secure > authentication technology. Today I think we'd require a security > layer from a SASL mechanism to consider it secure. Also cram-md5 > suffers from other defects. 1. You mean that MD5 is not a common, current practise that provides a useful degree of security? 2. Taking note of the exact language used in the sentence citing MD5 -- specifically the "may be sufficient", please supply alternative language. > o 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... .... > 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. 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. > email--appending disclaimors and doing all sorts of things. I'm not > convinced such is appropriate in this instance. Well, it certainly is a point that one could imagine deciding in either direction, in the abstract. So, yes, it is important that the folks who have been working on this document, and contributing to discussions about it, have extensive operations experience and made the choice intentionally. Are you raising a concern that the specified behavior will not work -- ie, it has a core, technical or operational flaw? Or are you simply expressing your concern that it is more strict than you would prefer? >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. That said, it is the presence of the submission port as an alternative to port 25 that permits the document to be so forceful about both requiring authentication on the submission port and prohibiting its blockage. In other words, the strictness of the spec was rather carefully discussed. It represents a moderately hard-won balance among the authors (and, by the way, the rest of the folks contributing to discussion during development of the spec.) There are good arguments for being even more strict, but we wanted the document to have the widest support possible. So, relative to much of the email operations community, the strictness you are reacting to is actually rather moderate... d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf