[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Content-length: - Re: Implementing SMTP server: some questions.
This entire thread reminds me of a long discussion that occurred in
the archives of MsgGroup way back in 1977, when someone at CMU was
building a new User Agent, and needed an "end of message terminator"
of some kind in his maildrop.
He set out to develop a "Network Standard End of Message Delimiter"
that would consist of some magic string of characters which would
always mean "end of message" when any message was to be transferred
across the ARPnet. This Delimiter was to be placed at the end by the
Now, this idea is a perfect example of a local matter being converted
into a network problem which requires network wide agreement about a
local matter. It is a perfect example of how to allow an EDGE issue
to creep into the CORE of a network infrastructure.
As the discussion proceeded, we finally detected that the root problem
was that the MTA in use at CMU was appending new mail to old mailboxes
without inserting any kind of Delimiter, though it always knew exactly
when a message ended, and could easily always insert a locally
defined Delimiter. Messages were always appended one at a time.
When the UA builder was apprised of this simple solution of asking his
MTA developer to simply put a delimiter of his choice at the end of
every append, the response was "I asked, but the programmer won't do it
for me, so I have to get the entire network to do it for me."
So, with this clear understanding that the CMU "end of message"
delimiter problem was a indeed local matter, the issue was closed and
no such delimiter has since been proposed...
... Until someone cocked up the Content-length: header, which is
supposed to be provided by the sender so the receiver will know how
long the message is after it is deposited in the recipients mailbox.
My view is entirely clear on this issue. It is a very silly idea, and
should be discarded promptly, for the same reasons as rejection of the
CMU "end of message" marker. It should only be generated by the
receiving MTA at delivery time, and should be stripped from any
If it is present on an incoming message, it should be understood that
its veracity is questionable. It should be confirmed by counting the
length, and if incorrect, should be corrected;-)...
Of course, the simplest implementation is to delete it and create a
new one, since you have to count anyway. What is the value of knowing
the the sending system disagrees with your delivery system count?
So, in conclusion, as I see all this, the advocates of Content-length
might soon be asking for a universal network end of message delimiter,
since that is the next logical neat thing to follow.