Julian,
The draft you submitted was badly needed, in my opinion.
I have a few comments:
5.1. The RSET Command
I have experienced the SMTP implementation in native AT&T SVR4 code to
drop the connection instantly when a RSET was issued. Quite annoying.
5.4. Behaviour with eight-bit data.
I wish someone had the power to force SUN to stop submitting 8-bit
Email messages without any restrictions in there OS. This is really
a pain in the a--. We constantly have to deal with customers using
a mixed environment with SUN workstations and PC with MS Windows.
Some customers cannot care less about Internet standards like MIME.
They say, "be compatible with SUN or we find someone else to do
business with". They never think about pushing SUN onto the track
instead, for obvious reasons.
6.1. Illegal format RFC-822 messages
What we really need is a true submission protocol, separate from
SMTP which by definition is a MTA-MTA transmission protocol. I have
had a feeling for a long time now that the current protocol suite
is unbalanced with respect of Internet mail exchange.
Recently IMAP4 finally made it to RFC status. Jolly good. But we
still have to rely on SMTP for submission. I never understood why
IMAP didn't contain a submit function. It is a client-server protocol,
isn't it? Several customers I have been in contact with, which knew
nothing about Internet mail protocols and formats, were astonished
when told that submission required no authentication what so ever.
6.4. Resent- fields
This is interesting. I have had a long arguing with a customer on
how to use these fields in practice. I found RFC-934 quite useful
in that regard. Anyway, when a mail containing Resent- fields is
fetched by a MUA, there are two possible intensions the resender
could have had in mind. Delegation or Information. In the case of
delegation the final recipient is expected to reply to the original
sender, not the resender. In the case of Information, the replies
is expected to be returned to the resender, not the originator.
But, how can the MUA tell what the intension was? I guess the
Information case would rather use ordinary forwarding with MIME
encapsulation together with a note describing to intension.
As a matter of fact, even delegation should use the same scheme,
in my opinion.
And what if the mail is resent a second time, should the Resent-
fields be replaced or duplicated? I have a slight hunch that they
should be replaced, or?
7. MIME issues.
Using a combined access and submission protocol in client-server
environments may have helped a little to decrease the entropy you
describe.
Well, that is all for now, I think...
--
Tomas Kullman <tomas(_dot_)kullman(_at_)pro(_dot_)icl(_dot_)se>
Embla Development Team
ICL ProSystems AB
SWEDEN