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