The things that make fax unreliable:

The things that make e-mail unreliable:

  • the recipient’s client tools decide incorrectly that the message is spam and stores the message where it will never be seen
  • the receiving mail server uses a DNSBL to…
    • …block connections from the sender
    • …accept and blackhole messages from the sender (ref outlook)
    • …accept and deliver messages to a place that is never visited
  • the recipient’s mail service decides for any flawed reason that the message is spam and delivers it to a folder that will never be seen
  • the recipient uses a spamgourmet.com address and forgot to update the counter thus causing the message to be blackholed or the service provider of the protected address blocks the spamgourmet.com server specifically
  • recipient’s mail server may reject the message if the domain name appearing in the From: field does not correspond with the IP address of the transmitting server (e.g. MUA allows freetyping the From: field and sender uses a spamgourmet.com address)
  • the recipient uses a forwarding service like Namesilo, who refuses to forward messages from unrecognized senders because the forwarding service considers their own IP reputation more important than the actual delivery of a single message
  • the recipient’s mail server uses graylisting with unreasonable delay. Time-sensitive messages can miss the deadline or sending servers can give up before the time lapse.
  • recipient’s e-mail server blocks the attachment (and possibly the whole email) incorrectly flagging it as malware.
  • recipient’s e-mail address is unknown because a webmaster’s anti-spam effort…
    • …is to not publish any email addresses. Senders are forced to use a contact form that’s blocked by a sometimes broken CAPTCHA. And when the webform does work, PDF attachments are not possible.
    • …is to block e-mail address disclosure until a CAPTCHA is solved, and the CAPTCHA is broken or the sender rejects the effort required
    • …entails hiding e-mail addresses until some javascript renders them, but javascript is either unsupported or disabled by the visitor’s secure browser. There is also no indication to the visitor that an e-mail address is even available if j/s were to execute.
  • recipient’s e-mail address is unknown because the webpage publishing it blocks Tor and the visitor will be damned if they must give up their security to view the page
  • the sender simply cannot send the message because the corporation who handles the recipient’s email (e.g. is a PRISM corp like Google or Microsoft) is not sufficiently trustworthy for the content of the message
  • large corporations use DNSBLs to force email senders to relay their mail through a static IP, and the sender with dynamic IP may not consider any third party sufficiently trustworthy to see all their emails
  • sender boycotts the recipients e-mail provider
  • recipient does not have an S/MIME cert. or PGP public key, thus failing to achieve the level of confidentiality required by the sender (some sys admins even refuse to accommodate encrypted e-mail in fear that a malicious payload will get past the organizations malware scanner)
  • recipient uses an EU-based e-mail service provider, where law obligates collection of metadata (a collection that may jeopardize the level of confidentiality required by the sender), and the recipient or sender are not using a Memory Hole-capable MUA to protect their metadata
  • recipient abandons their mailbox because they have other accounts and can’t be bothered to manage all of them, and unread mail piles up
  • sender is a technologically-challenged bank or brokerage who sends multipart MIME messages and puts in the plaintext part:
    • a message saying “Upgrade your mail client” instead of the actual message
    • a large dump of unreadable machine-generated HTML indistinguishable from garbage
  • sender attaches a file in a non-standard proprietary format like MS Word and the recipient cannot view it (or does not trust it to open it for viewing).
  • the email service requires users to solve a CAPTCHA, which may be broken, might refuse to send the puzzle to certain IP addresses, or the puzzle might not be understandable. Protonmail is an example of an email service that pushes CAPTCHAs.
  • jadero@lemmy.sdf.org
    3·
    11 months ago

    You’re probably aware of this, but apart from the very real problems associated with centralization on massive services and their desire to create walled gardens, a lot (most?) of the problems you list for email can be traced back to the problems of spam.

    Spam makes up the massive bulk of email and most of it is automated and distributed by botnets. Without a lot of the things you list, spam would make email even less useful than it is.

    I was once on the front lines of spam management. At the time, I calculated that spam and malware made up 70% - 80% of our company’s incoming email. That was 15 years ago. I can’t imagine things have got better or easier to manage.

    And you’re not alone. I know a lot of people who have email only for account management. They monitor their email during registration, add the relevant domain to the allow list, and send everything else to spam. Then they set their spam folder to auto delete anything older than about a month old.

    Email is, for all intents and purposes, dead for general purpose communications.

    • activistPnkOP
      2·
      11 months ago

      It is what it is. And fax is more reliable than email because of that “running goat fuck” (as the Scottish would say).

      There was also fax spam, but the response to that was not as self-destructive as it was with email. People lost their heads with email. The whole point to fight spam from an infosec standpoint was to maintain availability for legit email. But the vigilante overreaction by hot-heads behind orgs like SpamHaus aligned well with giant corporations who welcomed the idea of pushing out small providers. When ham is treated as spam, the admins are doing the work of the spammers: denying availability of legit msgs in a more direct way. The result is that the machinery 90% of the world depends on shit-cans copious RFC-compliant legit email in an effort to get zero spam in the inbox. That’s not the competent way to do it.

      Regardless whether you blame the botnets or the overzealous anti-spam vigilantes, the reliability of email is in the shitter.