ietf
[Top] [All Lists]

Re: Last Call: draft-hutzler-spamops (Email Submission: Access and Accountability) to BCP

2007-06-21 08:43:05


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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf