FUSSP: http://www.rhyolite.com/anti-spam/you-might-be.html
OK, thanks. :-) It's pretty clear that my proposal really IS that simple, and
really DOES go a LONG way to solving/reducing the problems of spams, worms, and
viruses.
I *do* urge the use of a good antispam content filter IN CONJUNCTION WITH my
proposal. My proposal, however, *greatly* improves the efficacy of the content
filter.
THE DEFAULT, for unknown/unspecified senders, would be to allow
through the mesh filter only mails smaller than a specified size
(say 25K or 50K bytes maybe) which contain no HTML and no
attachments... thus simple, text E-mails not exceeding the specified
maximum size.
So note that the proposal DOES NOT eliminate HTML-burdened mail,
nor does it impact ANY legitimate E-mail technology. It DOES mean
that UNSOLICITED mail from UNKNOWN senders would need to be sent (as
it SHOULD be anyhow, since the format is designed for universal
readability) as small E-mails using only plain ASCII text.
This is problematic at best.
Your objections are ridiculous....
...Many mail reading programs don't follow standards properly,
I'm sure that's true, but that doesn't impact my proposal. First, my proposal
is TOTALLY controlled by the RECIPIENT, so the recipient can set the filter any
way they like (hopefully using the same rules you'd use for setting the squelch
control on your 2-way radio... you want to block the noise while letting
through
all legitimate and trusted transmissions). Obviously, if you set the E-mail
"squelch" control to "minimum" then it won't help you much.
But anyhow, the fact that they "don't follow standards properly" doesn't really
affect my proposal one way or the other. My proposal should still work, and
one
can set the filter as aggressive (or not) as is appropriate for their situation.
...and even try to improve on perceived shortcomings
in the name of robustness. There is never any guarantee that an ASCII
message, sent as ASCII, will actually be displayed as ASCII rather
than some other format which the reading program thinks it can somehow
deduce.
And why, exactly, do you think that makes my proposal "problematic"?
Any filter of the type you propose must still second guess how all the
major current mail reading programs will interpret ASCII,
Why do you think that?
....under all their available options, settings and overrides. This is an
arms race exactly like the current one.
What does "how they interpret ASCII" have to do with my proposal?
It MIGHT have more to do with the proposed ASSOCIATED use of a good antispam
content filter (like Spam Assassin) but my proposal really has only VERY
limited
need (itself) to interpret the contents of the E-mail, beyond looking at
attachments and HTML tags.
Furthermore, typical spam messages are 2-3K in length, well below your
proposed limit.
Yes, and that causes NO problems for my approach. I'm NOT proposing that SIZE
be used to discriminate spam/nospam. I *am* saying that, along with
antispam/antivirus/antiworm goals, it ALSO makes sense that recipients be able
to prevent abusively large messages from being sent to them (and perhaps
chewing
up their limited-size ISP-provided Inbox) from people they don't know and don't
trust. (Limiting the size DOES, however, provide an additional way of
controlling incoming worms (from untrusted/unknown senders), most of which are
significantly larger than 25K).
This allows higher throughput at the spammer's end.
Throughput is generally not a problem for spammers and virus authors, since
they
as a rule don't pay for it, or at least they pay for a vanishingly small
percentage of the total bandwidth their actions cause to be consumed.
If the first step in your solution, namely blocking emails containing
nasty side effects, is ineffective,
I think you're misunderstanding my proposal. Either that, or you seem to be
misrepresenting it.
...then you are simply proposing a highly configurable whitelisting system,
with all the associated scalability issues.
Certainly it IS a "highly configurable whitelisting system" but with the key
property that you allow a significant and useful type of "initial contact" mail
through at least the whitelist part before going into the associated content
filter.
As for "scalability issues" you don't indicate why you think my approach is
particularly challenging in that area; certainly the whitelist portion is not
particularly resource-intensive (the content filter portion is the more
difficult part of the two main sections, but even THAT is greatly reduced by
the
reduced need to worry about HTML and other evasions).
While obviously it would be NICE to have spam filtered out as close to the
sender as practical, then you get back to all the issues about worldwide
consensus and all the rest, and I just don't think that's feasible at the
moment
(at least, I'll observe, it certainly hasn't gotten us very far up to now).
One
of the nice aspects about my solution is that it is ENTIRELY implementable at
the RECIPIENT end (and they get IMMEDIATE and substantial gratification upon
doing so), and they probably are not in any significant way inconvenienced by
the modest resources that my approach would use.
It would be ENTIRELY possible to implement it entirely within an E-mail client
(such as Outlook or Outlook Express for example) and wouldn't require ANY
changes whatsoever from the ISPs or the wider Internet infrastructure at
large... and because of that, it doesn't really require the issuance of any
official standards, either... (since in effect the recipient-controlled filter
ONLY really directly affects THEIR incoming mail) although a "best practices"
type document might recommend general approaches to use in implementing such
software, or to perhaps help avoid foreseeable issues or implementation traps
for the unwary.
Gordon Peterson http://personal.terabites.com/
1977-2002 Twenty-fifth anniversary year of Local Area Networking!
Support free and fair US elections! http://stickers.defend-democracy.org
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg