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(_at_)dotat(_dot_)at> http://dotat.at/
WIGHT: SOUTHERLY VEERING WESTERLY 4 OR 5, OCCASIONALLY 6 AT FIRST IN WEST.
MODERATE. RAIN OR SHOWERS. MODERATE OR GOOD.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf