Well, the new system will also need to have an acceptability, deployment,
migration plan probably with revamp cost estimates. Companies will expect it
to. The "great written" plan will make it available to increase
At any rate, I don't think anyone realistically believes SMTP will go away
anytime soon. I think in the final analysis, the new solution will need to
be or offer some level of backward compatibility (at a level that does not
break the fundamental security of the new system), and if not, no doubt, a
tertiary (3rd party) market of proxies, middle ware, etc, will evolve to
cover the gap. This would be a big $$$ window of opportunity for many
developers, not just the main vendors.
Can we solve the problem with the current system?
I think so. SMTPV2 (as you call it) can definitely backward compatible. I
think this group, as I understand it, offers us an "open minded"
opportunity to bring out all the issues that isn't oppressed with the idea
that we must be backward compatible.
In my opinion, the backward compatibility issues has minimized the potential
solutions that can be dreamed up.
In my opinion, I think this was what hurt the ASRG group because it basic
charter for "proposals" was to be based on Mr. Crocker guideline of current
In my opinion, I think this also speaks of the functional specification
that has it written in stone that it is inherently insecure and that nothing
was "enforceable" and that certain aspects are interpreted 2, 3 or 4
So in my opinion, under these conditions, we lost the battle before a single
shot was fired!
So I think we should just open our minds and bring it all out and then
narrow it down to a final solution. In think in the end, it will be a
SMTPV2 or something close to it. That's my opinion of course. <g>
Hector Santos, Santronics Software, Inc.
----- Original Message -----
From: "Paul Smith" <paullocal(_at_)pscs(_dot_)co(_dot_)uk>
Sent: Friday, January 30, 2004 5:41 AM
Subject: Re: Setting the stage
I must admit, I'm having quite a hard time coming up with things that I'd
want in 'mail-ng', that I couldn't do with the current protocols and some
Now, it is an argument that all the extensions make SMTP etc unwieldy and
hard to use, but any protocol that is going to be a core part of the
Internet has to be extensible or it's pretty much going to die. So, if all
that 'mail-ng' does is to make many of the extensions of SMTP redundant
then start having its own extensions, I think serious thought needs to be
done before obsoleting such a widely deployed protocol as SMTP.
That doesn't mean that I don't think a 'mail-ng' could be a good thing,
just that I think that many of the suggestions at the moment could be done
using SMTP extensions.
Maybe even some SMTP extensions could be made SMTP mandatory items. Eg if
people want to get rid of C-T-E, then why not make 8Bit transport
in SMTPV2. OK, you'll need a gateway system to allow SMTPV2 to work with
servers that don't upgrade from SMTPV1, but you'll need that anyway for
mail-ng to work with servers that stick with SMTP.
So, you could probably come up with a 'desirable' extension set to SMTP
that meets lots of peoples requirements, and then define a new TCP/IP port
number, new DNS RR record and have gateways. This would allow people to
make 'SMTPV2' servers without having to start from scratch. In this case
things like 8 bit transport would actually be easier as one of the reasons
people may not implement it is that they have to worry about converting
back to 7 bit for the onward server - if you know the onward server
supports 8 bit data, then lots more people would do it.
OK, now I've said that maybe 'SMTPV2' is the way to go rather than
'mail-ng', I'll try to come up with a few things that couldn't be done
without major modifications to SMTP - which would make it less SMTP-ish
than most current extensions do.
- I would like to get rid of anonymity. I agree with Eric Hall that there
are ways of having 'anonymity' which I'd be happy with. All I want to know
is that the person who sent an email was allowed to use that sender's
address. I don't care if the email address is
'g438dgsdj43y(_at_)anonymousremailer(_dot_)com', as long as I know that the
been given permission by anonymousremailer.com to use that address. In
case, if I get lots of spam from anonymousremailer.com and complaints
achieve anything, I can ban mail from that domain to my server.
- I would like to be able to know that if I get an email with an address
'fred(_at_)aol(_dot_)com' it has come from an AOL email server. This is
point above, but is subtly different. I know a lot of people like the
current ability with SMTP to be able to use a different email server to
send mail from their main email address, and who would oppose this (when
suggestions to implement a similar thing in SMTP have been proposed there
has been strong opposition from some people), but with proper
authentication you could use your 'home' mail server to send your outgoing
mail, so this wouldn't be a problem. (Sorry, this could actually be done
quite easily in SMTP, so it could be in SMTPV2, not in mail-ng)
- I would like my mail server to be able to look at a message
structure/headers/etc before being given the message. Sort of like the
IMAP4 'fetch' command, but on incoming SMTP-type mail connection (eg I get
a connection saying 'I've got mail for you', I can then respond and say
'Has it got any attachments, what are they?' before deciding to collect
- I would like to consider the possibility of having mail stored on the
SENDERs mail server. Eg, if someone sends me a message, I get sent a "URL"
which I can use to view/retrieve the message (not in a web browser -
although maybe that would be an thought..). This would make it easier to
have 'file sharing' without having to transmit the file to everyone. I'm
not convinced this would be a good idea, but I think it's worth thinking
- I would like enforced track-ability of emails. Eg, I send a message, I
want to be able to know if it has arrived at the other end. I would
actually like to be able to go back (within a time frame, eg 1 week) and
ask my mail server 'what happened to <such and such> an email'. That mail
server could then look at its records and say, 'I sent it to <xyz> mail
server', and then go and ask 'xyz' mail server, 'what happened to <such
such> an email that I sent you <whenever>', and so on until the SENDER can
get a trace of what happened to the message, if it got bounced somewhere,
where that was, if it got discarded somewhere etc
- I would like to see stricter conformance to standards enforced from the
beginning. With SMTP & current message formats we have a situation where
lots of MTAs/MUAs will try to interpret an incorrectly formatted message,
where other MTAs/MUAs will just not bother (which is OK, IMHO). This can
cause interoperability problems. I'd like to have the standards say
'incorrectly formatted messages/headers/envelope/etc should be rejected'.
This would make everyone do things properly (or they'd notice quickly
because EVERY other program they tested it with would reject it), and make
testing easier etc.
- Personally, I would like to get rid of being able to send inline images,
complex HTML etc in an email... I'm happy with "normal" attachments, I
could accept a bold/italic/underline/link etc formatting, but I don't want
messages at all, and have a basic email formatting style which is
Paul VPOP3 - Internet Email Server/Gateway