Hector,
I would add one thing to Valdis's helpful observations below...
The text in the last two paragraphs of section 2.2.1 of RFC 2821:
SMTP's strength comes primarily from its simplicity.
Experience with many protocols has shown that protocols
with few options tend towards ubiquity, whereas
protocols with many options tend towards obscurity.
Each and every extension, regardless of its benefits,
must be carefully scrutinized with respect to its
implementation, deployment, and interoperability costs.
In many cases, the cost of extending the SMTP service
will likely outweigh the benefit.
Is usually taken quite seriously. So you should not be
surprised if some of the responses to an otherwise-good
suggestion take the form of "that might help you, but most of
the Internet doesn't need it, so it isn't worth the clutter in
the protocol".
regards,
john
--On Monday, 12 January, 2004 23:11 -0500
Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
On Mon, 12 Jan 2004 18:02:30 EST, Hector Santos
<winserver(_dot_)support(_at_)winserver(_dot_)com> said:
Is this mailing list a good place to bring up and discuss SMTP
ideas/extensions?
As good a place as any..
How about the current RFC 2821 document. I have some
concerns and comments to make about it. I don't wish to
ruffle any feathers, make enemies and certainly, I don't
wish to go over stuff already covered or being handled by
some group or person, etc. I would like to do this the
"right way."
A good way to do this is to ask "Has anybody ever thought
about doing XYZ?". Quite likely, either somebody has tried it,
or thought about it. If not, we'll be happy to at least look
at the idea.
If you have an idea for an ESMTP protocol extension, feel free
to bring it up. Don't bother trying to do an entire spec
first, that's usually a bad idea. What you want to start with
are:
1) A problem statement: "I could tune my SMTP software to be
much more efficient if the other end told me XYZ up front.
Not knowing it means I have to do A, but if I knew XYZ, I
could optimize by doing B".
2) A *approach* to the problem - do you need to know XYZ
per-recipient, or per-connection, or would it make sense to
cache it per-site or per-domain?
3) Spend at least a little time thinking about obvious
problems - "XYZ only makes sense within a domain", "You'd need
prior arrangements to exchange data before using XYZ", "A
rogue client/server could horque things up by lying about
XYZ", and so on...
4) Be prepared for feedback, and be ready to incorporate it if
it makes sense. I can guarantee you that you'll possibly get
anything from "http would be a better way to attack that" to
"that won't work because there's a requirement ABC" to "if
you're going to do that, think about this too"...
And if you get flamed, just remember - there's people on the
list who are generally listened to because they've been around
and are generally wise and worth listening to. But I've said
dumb things here and been told so, and even having written
RFC822 won't save you from being told that you've come up with
a bad idea, so don't take it personally. :)