Re: Feedback on Hypertext Mail Protocol (a.k.a. Stub Email)

>> ...a typical intermediate MTA,
>> employing retrieval solely (or largely) for obfuscation purposes...
>
>Note that even if the benefits of obfuscation prove to be little or 
>none, the obfuscation technique would still be useful simply as a way 
>to spite the sender, which 99% of the time is a spammer.

Yes.  There are lots of techniques like that, which seem like they
would "fight" spam or "punish" spammers, by making email exchange
artificially more expensive.

I've come to believe making email exchange artificially more expensive
or less reliable -- especially structurally -- is not the right
direction for the industry, or, at least, not a direction in which I
personally have much interest.

(Note that you can "spite" a sender in SMTP by temporarily rejecting
each and every delivery after the DATA phase, and by also having lots
of spamtraps.)

>For most legitimate email senders, even if the amount of bandwith they 
>use for sending emails increases tenfold, it would still be much much 
>less than the amount of bandwith they use for other purposes, e.g. web 
>browsing, audio, video, games, graphics, etc. Perhaps this is not as 
>much the case in 3rd world countries yet, but in 2nd world countries I 
>think it is already the case (not to mention 1st world), and I don't 
>think the 3rd world is too far behind.

There's an insight there that I think is very important, and I believe
I've already touched on it before: of those sending emails, *only*
spammers fit a particular profile, that of trying to send a very large
number of (fundamentally) identical emails to as large a potential
audience as inexpensively as possible, with little or no concern for
whether any given recipient actually sees that email.

(Group deliveries of legitimate notifications such as "you requested
monitoring of www.example.com; it was just updated" come close to that
kind of behavior, but not all *that* close.  For one thing, recipients
have presumably already signed up to receive such emails, so spamtraps
are unlikely to be among the list of recipients.)

Artificially increasing the cost of exchanging email via techniques
that are designed with that insight in mind is one way to "solve" the
spam problem.  Especially if it takes advantage, and hence does not
require substantial replacement, of SMTP, that approach has
attractions.

Another approach is to fundamentally change how email is (typically)
exchanged, such that it better favors legitimate exchanges of email
over those who fit the spammer profile shown above than today's
typical SMTP exchanges.

I believe both SMTP and IM2000 can be "adapted" in that fashion,
though neither in as an ideal a fashion as an entirely new protocol,
and not by adding all sorts of artificial barriers to exchanging email
but, rather, by *lowering* some existing ones.

>So maybe eventually all spammers will find ways to be on whitelists.

Which brings us to the zombie problem, which I believe can be "solved"
(without simply defining it away) only via an appropriately adapted
existing protocol or a properly-designed new protocol, neither of
which is particularly on-topic here.  (The idea I have is to increase
requirements for zombie, or untrusted-bulk-sender, disk space
substantially, in conjunction with the increases in bandwidth
utilization we've been discussing.)

-- 
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>