ietf-smtp
[Top] [All Lists]

Re: rfc2821 New Issue: Section 4.3.2, the "anywhere" codes, and related topics

2007-12-01 13:26:06



--On Saturday, 01 December, 2007 13:56 -0500 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:


Bill McQuillan wrote:
 >
 > My copy of draft-klensin-rfc2821bis-06 would suggest 512
characters:
 >
 > 4.5.3.1.4.  command line
 >
 >    The maximum total length of a command line including the
 >    command word and the <CRLF> is 512 characters.  SMTP
 >    extensions may be used to increase this limit.
 >

Yes and note we have semantics for increasing but not lowering.

However, check this out:

       http://www.securityfocus.com/infocus/1654
...
What "bugs me" is the only reason they even suggest increasing
NOOP to
38   is to cure mail delivery problems with their own Exchange
servers
who are "padding NOOP."  Well, what about the rest of the
world?

Hector,

There is absolutely no question that this stuff exhibits a
problem.  The difficulty is that 2821 / 2821bis appear to be
fairly clear about what the right behavior is.  

The Microsoft knowledge base article you cited has a provision
for comments at the bottom.  I sent in a comment indicating that
the article was seriously off-base, and the behavior a violation
of the standard.  Who knows if that will do any good, but it
seemed like the right thing to try.  By contrast, as several
people have pointed out, making more changes to 2821 -- a
document that is being unread or deliberately ignored now--
won't help.

Almost the same issue applies to this Securityfocus piece.  The
author is wrong.  I don't know whether he is wrong because he
doesn't know that there is a standard, knows but hasn't bothered
to read it, or knows and doesn't think it is relevant.
Probably, someone who has the energy should write and comment,
either on that article or as a separate piece.   I assume that
they would accept, post, and link in such a piece.  If the
consequence of having such an article --one that was clear and
well-documented -- was damage to this author's credibility, that
would not be a bad consequence.  But it seems to me that the
cure for bad information is, where possible, corrected
information in the place where the bad stuff appeared.  

Saying something that is already said in 2821bis yet another
time (either in the document or on this list) is not helpful
unless it can be demonstrated that what _is_ there is ambiguous
or confusing to those who are reading carefully and wanting to
understand.  

    john




<Prev in Thread] Current Thread [Next in Thread>