OK, now we're getting into nit-picking details.
On Sunday, Mar 30, 2003, at 01:53 US/Eastern, Chuq Von Rospach wrote:
On Saturday, March 29, 2003, at 04:27 PM, mathew wrote:
With e-mail pull, I fail to get the mail if the sender's messaging
server (at his ISP) is down.
Or if the network between us is down, or if the server is overloaded
because someone who didn't know any better something to everyone in
his address book 100 times.
If the network between us goes down, then the mail doesn't get
delivered until the network goes up again. Just like if the network
between the sender's SMTP server and my mail server goes down with the
present system, the mail doesn't get delivered.
If an idiot sends something 100x to everyone in his address book,
that's unsolicited bulk e-mail, so the fact that I don't receive it is
a feature.
If someone forwards the mail, who's server is responsible for it?
Treat a forwarded e-mail as a regular e-mail that just happens to
contain an encapsulated message in the body. In other words, the same
as at present, the forwarder's mail server is responsible for delivery.
What server (if any) keeps the message for future reference?
What server (if any) keeps my e-mail for future reference now? None,
that I know of.
What if it's a person who never deletes his e-mail?
Then his hard disk fills up.
Or reads it 1000 times (DOS attack?).
Yes, if he has a broken mail client that doesn't download and cache the
mail, he might fetch it lots of times. Just like a broken web client
might fetch the same image every time it's included on any web page on
your site.
If it turned out to be that big of a problem, you could limit the
number of times your mail server allowed any given message to be
downloaded.
How long does a server have to keep a message to be read?
How long does an SMTP server have to keep retrying to transmit a
message? Configurable parameter. We can argue over what the default
should be, but I don't see that it needs to be decided right now.
What if the message is forwarded?
You already did that one.
what if the person posts a URL to access it to slashdot?
See above re: limiting number of times a message can be downloaded.
How does e-mail pull work in large environments where you have round
robins, load forwarders, and large strings of MX relays today?
Same way almost any other Internet protocol works. SMTP is an unusual
special case in that it had its own methods of controlling network
topology. Now that so much traffic flows through other point-to-point
protocols like HTTP, firewalls and switches are equipped to let you set
up "smart" routing based on protocol, source, destination, and so on.
Sure, you wouldn't just be able to translate your MX setups and e-mail
backbones to a set of firewall settings automatically, but that doesn't
mean you couldn't set up equivalent functionality.
How about through firewalls?
Well, you'd need to have a public messaging server outside the firewall
that people could contact to fetch mail your users sent, just like you
currently have a public web server so people can fetch pages your users
author. You'd also need a notification-receiving server, like your
current SMTP server.
I hate to say it, but email pull seems like a bad idea with a lot of
complexity for questionable improvement.
Yes, well, a lot of things on the Internet are a bad idea with
questionable performance. The web, IRC, Java, ...
Seriously, though, I don't see it as much more complex than running a
web server plus an SMTP server.
mathew
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg