ietf-asrg
[Top] [All Lists]

RE: [Asrg] AMDP

2003-03-12 12:31:06
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: foo(_at_)bar(_dot_)com
AMDP-NUMBER-OF-RECPIENTS: 5
AMDP-TO-NAME: u1
DP-TO: u1(_at_)yourdomain(_dot_)com
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>
  • RE: [Asrg] AMDP, ietf(_at_)centipaid(_dot_)com <=