Re: Email or Something Else

We defeat the purpose of solving the key problems the industry is facing if
backward compatibility is provided at the same level - aka LOOPHOLE!

So I see two things:

o Should not be backward compatible.

However, this will provide a barrier to acceptability and development,
therefore it should be:

o Should offer backward compatibilty with the following exception and
limits:

    - does not violate the any new security related concept mandated by
mail-ng
    - a X month grace/transistion period from the point of initial contact.

In other words, it could be just announced to the world.

       "Hey mail-ng is the standard now. SMTP/POP3 will be deprecated on X
date
        (24 months from release date). Everyone has 24 months to revamp."

or

       "Hey mail-ng is the standard now. SMTP/POP3 is be deprecated in 24
months.
        However, backward compatibility remain a system policy option. We
recommend
        using the mail-ng automatic "grandfather clock" where initial
contacts are sent
        an email warning there old compatibility access will cease to work
on X date.

Something.  It doesn't have to be so drastic, but then again, mail-ng serves
no purpose if it doesn't solve the problems we are facing and thus the
reason, atleast I think,  many people are here and are interested in new
mail system or "mail protocol" whatever you want to call it.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


----- Original Message ----- 
From: "Hadmut Danisch" <[email protected]>
To: "Bonatti, Chris" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, February 10, 2004 12:59 AM
Subject: Re: Email or Something Else


>
> On Mon, Feb 09, 2004 at 07:10:15AM -0500, Bonatti, Chris wrote:
> >
> > - We want backward compatibility, ...
>
>
> This requirement is nebulous, should be paraphrased in
> explicit requirements:
>
>
> - Should (temporarily=few years) be able to receive messages
>   through old SMTP/MX-Record. Maybe there could be a separate
>   gateway application, accepting SMTP and injecting it into
>   the new mechanism.
>
> - Should be able to deliver to old SMTP/MX machines.
>
> - Should be able to convert messages from old RFC822 to
>   new style and vice versa.
>
> - Should support UNIX world's /usr/sbin/sendmail injection
>   method.
>
> - (Maybe) should support MUAs with POP and IMAP (maybe through
>   a separate gateway process)
>
> Anything forgotten?
>
> Hadmut
>
>