meor(_at_)mail(_dot_)SoftHome(_dot_)net wrote:
First of all the problem is not limited to web clients. It's a problem
for everyone who offers a free email service, regardless what clients
their "customers" use.
No, the "problem" is that you're applying the current E-Mail system to a
different method. If you read the method through, you'll see that there
are no relay agents in the protocol. There are send clients(computer
users trying to send mail), mail hosts(server which houses mail messages
for later retrieval by an end user), and end users(people who are
getting the mail). When you send mail, you're sending to the mail host,
you do not send to an ISP SMTP server which in turn relays the message
to the final server. Like every other server/client setup on the
Internet, if the mail host is down, your message cannot be sent at that
time it does not get "cached" somewhere until the SMTP server decides to
bounce it back.
Your "simple solution" is bad.
I think you're misunderstanding it.
Example:
Dial-In user ---> ISP's/freemailer's relay
relay --> final destination (temporally unreachable)
Dial-In user goes offline
relay (retrying) --> final destination
If the final destination is a malicious pseudo server, the *relay*
will have to handle the requested, impossible authentication task.
There are no relay servers. If the mail host gives you an impossible
task, only the send client will be tied up.
Every mail client would have to become a full mail server with MX'ing,
queuing and the rest of the 9 yards. Sending an email to large numbers
of recipients (especially mailing lists) would become extremely unreliable.
There goes any chance for rate limiting, send filtering, or even logging
(especially in a corporate environment). Legitimate bulk mailing would
become excrutiatingly painful.
I think this cure is worse than the disease. It'd never fly in a
corporate environment.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg