Re: Setting the stage

Hi Paul.

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
acceptability.

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
SMTP support.

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
different ways!

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.
http://www.santronics.com





----- Original Message ----- 
From: "Paul Smith" <[email protected]>
To: <[email protected]>
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
> extensions..
>
> 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
and
> 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
mandatory
> 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
email
> address. I don't care if the email address is
> '[email protected]', as long as I know that the sender
had
> been given permission by anonymousremailer.com to use that address. In
that
> case, if I get lots of spam from anonymousremailer.com and complaints
don't
> 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
> '[email protected]' it has come from an AOL email server. This is related to
the
> 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
it)
>
> - 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
about.
>
> - 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
and
> 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
> tables, javascript, DHTML etc in an email... I'd say stop allowing HTML
> messages at all, and have a basic email formatting style which is
formatted
> differently
>
> Paul    VPOP3 - Internet Email Server/Gateway
> [email protected]   http://www.pscs.co.uk/
>
>
>