[TriLUG] postfix spam blocking

[Kevin Hunter]

At 2:54pm -0500 Fri, 16 Dec 2011, Jym Williams zavada wrote:
> Hence the many problems we have with spam, CEOs who complain about
> e-mail delays, and so on. The sad fact of the matter is that the
> current e-mail infrastructure really is due for a complete overhaul,
> but it is unlikely to happen because we are already depending on it
> too much.

I've had in the back of my mind an implementation of one such overhaul 
for quite awhile.  At least as regards the spam issue, I think it boils 
down to who bears the (relative) cost of an email.  In a postal world, 
it is the sender; in an email world, it is the receiver.  (Cost is 
mostly monetary in a postal world, but it may be more time-specific in 
an email world; as-in the time/electricity it takes to parse an email, 
decipher it enough to realize it's spam, and click delete.)  Thus, my 
completely unprofessional, 
30-seconds-of-thinking-about-it-therefore-I'm-an-industry-expert 
solution involves switching the burden of cost.

The gist of my scheme involves recognizing that (99% of) email servers 
are on 24/7, and redefining the push part of an email to be only the 
headers.  (A "conforming" MTA would strip any part of the message that 
is not a header.)  The MUA would scan the headers for a URL of where to 
download (pull) the actual body of the message.

Changes from the user-experience now
  - Not a whole lot.  The MUA can be set to download automatically
    the body or not, like it is today.

  - Assuming no messages are spam, the total amount of information
    a MUA will download is the same as is today (plus some change
    if your counting)

  - If some messages are spam, the MUA does not have to download
    them at all.


Changes from the infrastructure point of view
  - A new web service to handle email header URLS must be set up.

  - Email now /requires/ the sending service to be net accessible
    /when a MUA checks email/ for recipients to receive anything.

  - Less total data is spent on effectively useless transferred
    bytes/data.


There are more details, but in my "expert" opinion, a basic 
infrastructure like this would still easily allow services like 
encryption, digital signatures, web email, while at the same time 
requiring more accountability/investment from spammers.  If a site can't 
be reached, its email won't get delivered, end of discussion.

Anyway, my 30 seconds and 2-cents on how to solve or at least address a 
majority of the problems with email.  Has anyone else given this issue 
any thought?

Cheers,

Kevin