Subject: RE: [Asrg] AMDP

From: "[email-masked]" <[email-masked]>
Date: Wed, 12 Mar 2003 19:37:34 GMT

Hi Kee

> >Note that there are two scenarios
> >
> >1. Email is not allowed in, and only the envelope is
> >2. Email is allowed and delivered as current system.
> 
> Ah, okay that makes sense.  Of course it doesn't fix the
> problem for  the SMTP reader of your email.

The AMDP server will know it is talking to an SMTP server,
from the HELO so it depends on the MHF implementation on
what
to do.  

  1. it can act as other SMTP servers and send the whole
thing
  2. It can send the URL.

I had to think a little about your previous comment that URL
could not support attachment, and I think a good transtional
MHF solutions will include a similar interface to what we
see 
today in web emails so all the attachment will be accesible
and 
can be downloaded. 

> that time >they are removed.  This does not happen in SMTP
> and mail >will
> >stay forever :(
> 
> Presumably people aren't going to set the expiration date
> every time.  They'll use some default (e.g. 30 days).  So
> the ISP goes from a  situation where they store incoming

The MHF sets the ultimate expiration date, so if a users
sets
the message to 60 days, but the max days set by the MHF are
30,
then the date is changed to 30.  However note that
expiration
is used to clean up things, and not as a limiting factor.
outgoiung
mail quota is the limit. For example your ISP will say you
have
10M web space, 50 email accounts, and 100 Mb outgoign mail
quota.
The user can do whatever he wants with those 100.  The ISP
is charging
and sizing his business accordingly..

> BTW, I don't remember.  If you get a bounce from a
> recipient, does  the server notice this and remove that id
> from the list of pickups it  is expecting?

I did not include that in my initial proposal, but it is a
valid
point and will definetly add it and see how it will be
managed

> For instance, I know a very large insurance company that
> requires  special permission for their employees to use
> the web.  Mail sent  from your system to theirs (until
> they move to your system) will be  unreadable by those
> employees. 

There will be a transition and you can always find a
solution
regardless of the issue.  If it does not work for them then
it
will not becuase of their business rules, and not becuase of
the
technology.  They can always adapt, add filters, gateways,
etc..
if they feel that it benefits them.

> >  > - It is no longer possible to send a single message
> to >>  multiple  people and let the remote system explode
> it. >
> >Actually the MHF does a better job in managing space than
> 
> Space yes.  But not traffic or time.  The time to send
> notifications  increases because you have to send them one
> at a time. 

You made a golden point here, thank you!  I did not think of
this
before, but I went back to the drawing board, and found out
that 
the protocl should support this, and it can do it (after all
it is
supposed to be adaptive :))

So from your suggestion is makes sense if an MHF is sending
an X
amount of emails to one repient, then the envelope will have
the 
same information outlined in the design, but instead of one
email
it will contains one addtion header that will tell the
receiver 
gateway how many emails are getting the same message, and
list them
in order.

For example a header will look like this

AMDP-FROM-NAME: Name
AMDP-FROM: [email-masked]
AMDP-NUMBER-OF-RECPIENTS: 5
AMDP-TO-NAME: u1
DP-TO: [email-masked]
AMDP-TO-NAME: u2
AMDP-TO: u2yourdomain.com
AMDP-TO-NAME: u3
AMDP-TO: u3yourdomain.com
AMDP-TO-NAME: u4
AMDP-TO: u4yourdomain.com
AMDP-TO-NAME: u5
AMDP-TO: u5yourdomain.com
SUBJECT: Message to all
AMDP-MAIL-CLASS: DIRECT::BULK::foo
AMDP-LANGUAGE: EN
...

This will work also very nicely when contacting the MHF
so instead of downloading one message or envelope at a 
time. One message is read and passed to all recepients.

Thanks it makes the system work better in bulk 
communications.

> >  > - All my recipients get annoyed at me because they
> >  > can't read my  email without following embedded links
> in it. >
> >:) If you are emailing someone one using older SMTP
> servers, >they wll get that actual message like today. 
> Only if they >have
> >AMDP servers that they could either get the message or
> the >link.
> 
> Okay, this wasn't clear.  How do you know which I have? 
> Is there a  new kind of DNS lookup?  Or do you assume that
> the new server sits on  the same MX server?

In the HELO hanshake...

> And if that's the case, why all this discussion about
> transitionally  including URLs in the email body, and
> people using browsers to view  them?

The disccusion was assuming that the receiving server is
AMDP
as well, while the customer are using older clients. If the
recpient is using SMTP they will never see AMDP it is
transparent
to them.  Only AMDP interactions will follow the outlined
process.

> >Right! If I am the only one in the work using it it will
> not >work, unless I have 20-30 million email accounts that
> people >want to email, and then they will listen.
> 
> But how do you get from "just you" to "20-30 million
> accounts"?  Your  only hope of success is that AOL and a
> few other major ISPs decide  that they are going to do
> this and warn the world that they are going  to flip the
> switch in 12 months.  Then the rest of the world all 

I own and manage an email service supporting over 1.5
million
users, but the email service is free, so moving into this
model
will just make the senders not email the people on my
network.
BUT it if it is big enough and all your friends and contacts
are on that network then you will have to get a certificate,
classify your email, use an MHF, to avoid paying postage..

If you are a small guy user you will be able to use an ISP
with
AMDP support, or use a third party company to email that
network
until you do.  Or pay the postage.  The design is flexible
enough 
to allow willing participants to email te nwteork, and tough
enough
on the spammers that will not play the game.  If spammers do
get the
certificate, and mhf, they will pay a fraction of the fee if
they do 
not, and most likely their messages will never make it to
the target
audience they bank on..

> upgrades their mail servers to the new software. 
> But that isn't going to happen.  The rest of the world
> can't manage  to apply simple security patches to their
> email server and yet you  expect them to all jump and make
> this change?  You're best case is  that people will
> provide transitional gateways between the two 
> systems--and then the spammers will sit on the old system
> and throw  spam through the gateways.

That is true change takes time, and the proposal is just a
draft
when enough people feel that it has enough good points to go
forward then the following will happen.

1. Put a clear transiontal plan, that includes technical,
and marketing.
   encouraging open source software to add feature that will
allow the
   technology to be usable

2. Put together a clear development plan.

3. Have the protocol examined, find vunerabilties and fix
them before
   implementation.

What encourages me to follow this model is that it what we
use today in USPS, and other mail carriers worlwdide.  It is
just an adaptation, and we know from real life that spam is
much more controlled in comparison to what you see online. 
I never open my home mailboz to see 200 pieces of junk mail.
 I see 3 - 5, and that is because of the economy of cost to
the sender.  And that is what AMDP is all about the
specifics will definetly show up as individuals like
yourself find those features that are key to making the
process worth while.

We can not spend out lives playing cat and mosue with
spammers, change the process to make them accountable if
they do not want to be, then let them have fun in SMTP world
until there is no market worth pursuing, and ultimatly will
play along..

> I've never seen business going around respecting other
> businesses  decision to hurt themselves.  Laugh maybe, but
> not respect.  What  possible reason would there be for a
> business to use this system to  restrict their incoming
> email to solely those other companies who  have deployed
> it.  We've created a world-wide network that is  dependent
> upon communication.  Nobody can afford to cut their links 
> from that. 

I did not mean that they will use AMDP, but if I have AMDP
installed and they receive a response saying that it costs
them 0.002 to email us, since they are not using AMDP, then
they will pay the 0.002 to get business done.  

> I mean, if you want to solve the problem by creating an
> entirely new  protocol, there's no need to create one from
> scratch.  We can all  just step back a decade and take the
> email branch we abandoned.  X.400 should provide all the
> infrastructure we need to prevent spam. -- 

I saw you post on X.400, and I am sorry that it did not make
it, but you can not base eveythring you see on previous
experience.  I myself have dealt with AINC working on
multilingual domain names, and have seen technologies go up 
in smoke, and some are very good.  

The fact they are chewed and spit is not a measure of how
good or bad they were. Competition, and special interest
play a major role in it too.  Propoenents of email filters
can keep saying "my filter is better than yours", but when
will it stop?? If I felt that the future stands to keep
email as it is, then I would not even try :))

Cheers
Adonis

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 12 Mar 2003 21:25:03 -0500

>today in web emails so all the attachment will be accesible

I would recommend just sending the whole body.  Otherwise you've 
completely destroyed my filing system by not sending me the content 
of the message.  I'll end up cut and pasting the message from the web 
site and mailing it to myself (and sending you a nasty response).

>if they feel that it benefits them.

But you've given them no choice in the matter.  They are running 
SMTP. You're sending via your new system that sends them a link.  As 
a result, you can no longer communicate with your insurance company. 
Now which is going to happen?  They are going to change their 
security system to to accommodate a few early adopters?  They are 
going to implement a brand new system that may never take off?  Or 
they are going to tell you to go back to using SMTP if you want to 
communicate with them?

>they will pay the 0.002 to get business done.

It all depends on leverage.  If you are one customer, and they have a 
hundred more who use SMTP, then they are going to tell you to take a 
hike.

>it, but you can not base eveythring you see on previous

I'm not.  X.400 was a horrendous idea.  Massively centralized, and 
based on the assumption that email would be run by government 
organizations like the post office.  The addressing mechanism was 
unusable without a global directory service, and addresses were 
completely non portable.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg