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).