On Thu, 21 Jun 2007, John C Klensin wrote: > > (2) Section 3.1 contains a MUST requirement for availability of the > message submission port (RFC 4409). While I am a firm believer in RFC > 4409 and look forward to the point at which we can put out a document > that deprecates the use of SMTP (RFC 2821) for message submission by > clients that do not support full SMTP services (for many more reasons > than spam mitigation), we aren't there yet, and a MUST requirement > definitely does not represent current practice. It does represent *best* current practice, and I think it it reasonable to say that a site is not conformant to draft-hutzler-spamops if they don't support RFC 4409. I don't think this document is trying to say that all sites will have to adhere to all the MUSTard, just that they can't claim to be following best current practice if they don't. > It seems to me that the provision that the tracing requirement of > "Submission Accountability after Submission" can be satisfied by > examining header information requires a comment, either inline or in > Security Considerations, about the ease or difficulty of spoofing that > information. It says "based on" which I read to mean "in combination with logs", and I think the comments about how long it is possible to trace a message refer to log rotation. In which case spoofing isn't something to worry about. However I don't know why it is so vague about mechanisms. > The Section 4 recommendation to use Submit on port 587 rather than SMTP > (on port 25) for initial submission is wonderful, and consistent with > the recommendations in Section 3 and elsewhere. But there is ultimately > nothing magic about Port 587 other than that most providers who are > providing crude blocks on port 25 haven't awakened to Port 587 yet _and_ > that Submit requires authentication and SMTP does not (see comment (3) > above). It might not be magic, but the authentication means that the operator of the MSA has a relationship with the sender and therefore has meaningful responsibility for and control over any email - contrast port 25 where there is no authentication and the operator of the MTA is a victim who has no reliable way of telling good from bad traffic. > (5) A MUST NOT requirement on blocking Submit (Section 4.1) is a bit > dubious at this point. Again, I am sympathetic to the reasons, but > there are presumably still implementations of RFC 2476 out there that do > not require authentication. An access provider has no way to be > guaranteed that all servers on port 587 authenticate and authenticate > adequately (i.e., there is no trust relationship between an access > provider and an arbitrary port 587 server at all). So, if the access > provider believes that blocking outbound port 25 is an important > anti-spam measure, then blocking port 587 traffic to an open relay on > that port is equally rational. I think that demotes this requirement to > a SHOULD, with as strong an explanation as the authors deem appropriate. No, because an open relay is the responsibility of its operators, not the responsibility of every access provider on the net. You need to distinguish direct attacks from indirect attacks. Tony. -- f.a.n.finch <dot@xxxxxxxx> http://dotat.at/ WIGHT: SOUTHERLY VEERING WESTERLY 4 OR 5, OCCASIONALLY 6 AT FIRST IN WEST. MODERATE. RAIN OR SHOWERS. MODERATE OR GOOD. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf