Couldn't a matrix client with email and asynchronous features be a drop-in replacement for email ? Wouldn't that be a killer product ?
SPF, DKIM, and DMARC are not to core to email protocols if I understand correctly.
There shouldn't be a way for a matrix a client to delete a message sent to another client to keep with the email usage and expectation. So matrix messages wouldn't necessarily be used as email text messages but attached documents to messages would carry email that a client would store and archive.
As the article mentions, Microsoft’s server was telling the sender that it had accepted it. An ACK had taken place. But there’s no point in having an ACK if the recipient lies about it.
Tbh queued for delivery doesn't mean the email has been successfully delivered, BUT, the mail server should inform the user if a delivery cannot be performed.
Most probably this whole problem realted to silently dropping emails is intended behavior, a type of shadowbanning applied to emails to prevent spammers from knowing their email was blocked.
Too bad that this in turn causes huge issues for legitimate users
If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message. This
notification MUST be sent using a null ("<>") reverse-path in the
envelope. The recipient of this notification MUST be the address
from the envelope return path (or the Return-Path: line).
And:
As discussed in Section 7.8 and Section 7.9 below, dropping mail
without notification of the sender is permitted in practice.
However, it is extremely dangerous and violates a long tradition and
community expectations that mail is either delivered or returned. If
silent message-dropping is misused, it could easily undermine
confidence in the reliability of the Internet's mail systems. So
silent dropping of messages should be considered only in those cases
where there is very high confidence that the messages are seriously
fraudulent or otherwise inappropriate.
The RFC makes clear the long-standing principle that a mail-server operator is entitled to make his own rules as to what mail he is and isn't willing to accept. But he's NOT allowed to accept it for delivery, and then silently discard it.
Hotmail was always awful for this. There are comments up-thread to the effect that Microsoft might be trying to squeeze out self-hosted mailservers. I suspect that was the case in the Hotmail days. Either it worked, and nobody self-hosts any more (FALSE) or it didn't work, and they should have given up. I suspect the same policies are still in place due to corporate inertia.
Email is a delay/disruption tolerant network, and each hop in the network has a positive acknowledgment that the message has been committed to stable storage (a high bar). If the final destination rejects the message a delivery failure message is sent to the originator if one was specified (it's not mandatory), otherwise the postmaster is notified.
In general, I think whatever you are suggesting will not have all the same guarantees of delivery as email.
and each hop in the network has a positive acknowledgment that the message has been committed to stable storage
If that were true there wouldn't be silent drops in the last mile.
In general, I think whatever you are suggesting will not have all the same guarantees of delivery as email.
ACK is not to guarantee that messages are delivered though. It's a mechanism that ultimately would let the sender know the message was most likely not delivered.
You can't ever replace email because Microsoft, Google and all the other big players will try to push their own proprietary solution instead of agreeing on a new federated protocol.
Let me know when that new client is default installed on the phones and laptops of, say, 70% of all people. I’ll start taking a look at it and evaluate it against standard smtp/imap/pop3 then.
Comments
So, basically, email lacks an ACK mechanism.
Couldn't a matrix client with email and asynchronous features be a drop-in replacement for email ? Wouldn't that be a killer product ?
SPF, DKIM, and DMARC are not to core to email protocols if I understand correctly.
There shouldn't be a way for a matrix a client to delete a message sent to another client to keep with the email usage and expectation. So matrix messages wouldn't necessarily be used as email text messages but attached documents to messages would carry email that a client would store and archive.
As the article mentions, Microsoft’s server was telling the sender that it had accepted it. An ACK had taken place. But there’s no point in having an ACK if the recipient lies about it.
Tbh queued for delivery doesn't mean the email has been successfully delivered, BUT, the mail server should inform the user if a delivery cannot be performed.
Most probably this whole problem realted to silently dropping emails is intended behavior, a type of shadowbanning applied to emails to prevent spammers from knowing their email was blocked.
Too bad that this in turn causes huge issues for legitimate users
Not "should"; it's a "MUST".
And: https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.4The RFC makes clear the long-standing principle that a mail-server operator is entitled to make his own rules as to what mail he is and isn't willing to accept. But he's NOT allowed to accept it for delivery, and then silently discard it.
Hotmail was always awful for this. There are comments up-thread to the effect that Microsoft might be trying to squeeze out self-hosted mailservers. I suspect that was the case in the Hotmail days. Either it worked, and nobody self-hosts any more (FALSE) or it didn't work, and they should have given up. I suspect the same policies are still in place due to corporate inertia.
Microsoft ignoring standars? Impossible!
Fair enough.
Email is a delay/disruption tolerant network, and each hop in the network has a positive acknowledgment that the message has been committed to stable storage (a high bar). If the final destination rejects the message a delivery failure message is sent to the originator if one was specified (it's not mandatory), otherwise the postmaster is notified.
In general, I think whatever you are suggesting will not have all the same guarantees of delivery as email.
If that were true there wouldn't be silent drops in the last mile.
ACK is not to guarantee that messages are delivered though. It's a mechanism that ultimately would let the sender know the message was most likely not delivered.
You can't ever replace email because Microsoft, Google and all the other big players will try to push their own proprietary solution instead of agreeing on a new federated protocol.
Sure.
Let me know when that new client is default installed on the phones and laptops of, say, 70% of all people. I’ll start taking a look at it and evaluate it against standard smtp/imap/pop3 then.
Sure.
But in these days and age of webmail I am not sure 70% of people have a mail client.
I don't really understand the argument of pitching mass adoption against something that doesn't exist yet.