Tony Finch wrote:
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.
Not sure whether John continues to confuse statistics with quality -- that is,
how much sites currently support port 587, versus the anti-abuse operation
community's view of whether supporting it is a good idea -- but as you note,
supporting 587 most certainly *is* considered advisable by the anti-abuse
community. The simple act of separating posting from delivery streams
improves the ability to make posting activities more accountable.
As for the semantics of a MUST in an IETF document, it is interesting that
confusion persists between "everyone everywhere must always do the MUSTs that
the document dictates" versus "anyone claiming to conform to this document
must always do the MUSTS that the document dictates." As you note, the
semantis of an IETF document are the latter, not the former.
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.
In developing the document, we tried to keep away from anything that was
controversial, in preference to getting a document that could be widely
accepted. With respect to discussing the details of any particular mechanism,
there is simply too much variance in the operations community.
It would have been too easy to try to make the document be a primer on email
operations; we chose not to do that. Since Received header field analysis is
tricky business, any meaningful discussion of the process would have required
extensive pedagogy about email basics.
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.
Nicely said. And, of course, correct.
(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.
NS. A, oc, c...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf