1
Why fax is more reliable than email
(slrpnk.net)
The things that make fax unreliable:
- some idiot in the office dumped the faxes and took out the garbage before reading them. (source)
- the fax runs out of paper, reports a "success" ack to the sender, and then neglects to continue the job when paper is refilled (source: https://mirror.us.oneandone.net/projects/media.ccc.de/congress/2018/webm-sd/35c3-9462-eng-deu-fra-What_The_Fax_webm-sd.webm)
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 theFrom:
field and sender uses aspamgourmet.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.