Re: anti-spam software for home use

From: *Vanguard* (no-email_at_post-reply-in-newsgroup.invalid)
Date: 03/08/04 

Date: Mon, 8 Mar 2004 01:44:00 -0600

"Alan Connor" said in
news:AWQ2c.8830$%06.3884@newsread2.news.pas.earthlink.net:

<snip>
> I posted a *mock* RFC a long time ago, an attempt at arriving at some
> standards for the use of C-Rs in internet mail, but know of no actual
> RFC on the subject.
>
> It wasn't really an impressive article, frankly. If you want to work
> on another one I'd be happy to chip in.

I found a draft at
http://www.ietf.org/internet-drafts/draft-irtf-asrg-cri-00.txt. It
never does adequately the currently unintelligent mechanisms for
addressing the challenge which results in sending "challenge spam" to
innocents who had nothing to do with sending the original spam. It
mentions other work in progress, MsgTrk WG, some worgroup in IETF
regarding how to track messages but from what couple of searches that I
read at IETF this seems to assist the *sender* of a message rather than
the recipient. The draft notes that many C-R schemes have no way to
adequately identify the real sender. It also appears the draft has no
intention of usurping or referencing other work in progress on providing
better tracking of e-mail (to *remove* anonymity). Whatever tracking
improvements show up will probably be adopted, but then as tracking
becomes more robust then the need for C-R will wane.

So it appears that we still need to wait for absolute tracking of sender
to get employed in the e-mail scheme (and then wait for it to get
implemented). Until a decent means is available to correctly identify a
sender (or to detect that the sender cannot be identified adequately
beyond some threshold), I don't see C-R going mainstream for e-mail. It
is yet another "personal-use" solution for eliminating undesirable
e-mails. There's no point in exchanging one problem (getting spam) with
another (getting "challenge" spam) for business or professional use
until at least this draft gets more polished so e-mail clients can
adequately implement automated internal procedures in handling then
standardized C-R messages (when and if it ever gets standardized). The
draft mentions having the MTA do the automated response but that again
is rife with spammers automating that response to force their crap to
get through your C-R client. The fallback will be for MUAs to automate
the handling of C-R messages but that's not going to happen until C-R
gets to a much more common usage than now and probably not until the CRI
draft becomes an ratified RFC. Your solution appears to be an MTA
solution employing a C-R scheme but most e-mail users have no means of
effecting a server-side solution, so they'll have to wait until CRI
becomes widespread enough within MUAs to make it a viable solution. As
yet, I see nothing in the CRI draft that would lead me to believe that
C-R would ever be practical for business use where is probably the
highest amount of e-mail being produced by users; i.e., a company of 500
employees produces far more e-mails than those same 500 employees when
they go home to use their personal e-mail.

It seems it will still come down to implementing new e-mail protocols
(incompatible with existing e-mail protocols to avoid bastardization of
trying to merge or connect the two) that enforces full tracking to
sender and where anonymity is impossible yet where, for a price, you can
acquire anonymity (which would be unaffordable to spammers) but also
realize your messages become suspect and liable to spam-like filtering
(much like subscribing to caller ID where you opt to refuse calls from
callers that don't identify themselves). I won't get into the schemes
that have been proffered so far. While most opponents state that there
will be a huge resistence to changing or trashing the current e-mail
protocols, that's not true if development were in parallel where both
e-mail schemes were available for evolutionary or revolutionary change,
and it seems the Internet2 would be a ripe development environment for
that.

> Not me. Are you talking about a replacement for SMTP, which a lot of
> mail pros think is badly in need of replacing?

No, Internet2 is a consortium of universities and maybe some large
companies in providing their own privatized network over existing
technology to develop solutions separate of the hassles of using the
standard Internet. In fact, I believe it started out as a need for
better (faster and more reliable) communications and a internetworking
environment more geared towards the needs academia.

> In my opinion, it needs only this change:
>
> The number of Bcc addresses, not the addresses themselves, should
> be included in the headers.

Since none of the headers included in the DATA command to the SMTP
server (which includes both the headers and body) are used in specifying
the recipient(s), why would that help? The sender can put anything they
want in those headers because it is part of their data that they
compose. The To, Cc, Reply-To, and Subject headers are actually all
optional. The Bcc header is never supposed to appear because the
aggregate of recipients from the To, Cc, and Bcc fields get specified in
RCPT TO commands sent from the client to the server. In fact, many
recipients of spam will note that the To and Cc headers don't even
contain valid syntax for e-mail addresses and may just contain another
spam string. The SMTP server has no clue that one RCPT TO command was
for a recipient listed in the From header and another RCPT TO command
was for a recipient listed in the client's Bcc field (which usually does
not get included in the DATA content sent to the SMPT server). I guess
I never thought about relying on anything in the Bcc header (which is
only shown in the recipient's for *defective* mail servers that don't
strip it out of the DATA content or *defective* clients that put it
there in the first place) because I never figured spammer, except for
ineffective newbies, using the Bcc header in trying to hide.