Re: [Asrg] Introduction and another idea

[[e-mail]]

> ...Now, about whitelists.
Setting the parameters for what's acceptable from whom, sure, I'm all for that.
And whitelists are good as a pre-filter filter for assuring that mail 
that must be delivered gets through, and whitelists improve over time.

> The hard part is not defining what such a list might look like 
(though I would suggest that standard MIME types be the determinant)

> The hard part is the maintenance of the list, and then dealing with 
the problem that senders are not authenticated. The issue gets stuck 
on this, and nobody's talking to it. 

Actually, that's very much a part of what I wrote about... and I suspect you 
didn't read my proposal very thoroughly (or else you just didn't understand it).

The point being that spam is at least 3-5x bulkier, FAR more difficult to 
identify, and far more dangerous, if it can incorporate (1) HTML, (including 
clickable hotlinks, images, scripting, and so forth), (2) attachments (virtually 
all worms and viruses are based on attachments), and (3) base64 or other 
encoding.  By restricting all of those features BY DEFAULT, there's only a 
relatively small number of senders for any given recipient who can send them 
mail containing those things.

UNSOLICITED MAIL (and yes, we ALL get that, and many times we WANT to get it... 
e.g. new prospective clients, consumer feedback, etc etc) basically NEVER needs 
to contain those things.

> The easiest rule is that anyone I've written to, can write to me. 

Please note that my proposal is WAY different than what you seem to be thinking 
it is.

   1)  I *absolutely* do NOT give carte blanche send permissions to just anybody 
that I've written to;  most of my correspondents do NOT _need_ to send HTML, 
attachments, or encoded text message bodies (and fewer still need to send me ALL 
of those);

   2)  The stated intention of my permissions list approach is NOT to PREVENT 
all conceivable spam.  Plain ASCII text spam containing no attachments will 
still get through my approach just fine.  But the stuff getting through from 
unknown and/or unauthorized senders will:

      a) be [typically MUCH] smaller than HTML-burdened spam, or spam with 
attachments or encoding;

      b) not contain links and URLs which purport to be one thing but actually 
point somewhere else;
   
      c) not contain text-in-GIF/JPG format or scripts or other such "obscured" 
content that flummoxes content filters

      d) not contain attachments containing worms/viruses/etc.

> But beyond that it gets very messy. 
Simplest example: I hear from a LOT of people I don't know at all, 
who are writing for absolutely legitimate reasons. 

Absolutely... a good example would be mail coming to 
[e-mail]... you ABSOLUTELY don't anticipate who will write 
to you if you deal with large numbers of consumers at large.

> Counter example: 
The new e-mail worms pull sender and recipient addresses from the 
same address book... my friends have received such things "from me", 
(that I of course didn't send). 

Absolutely.  But note that those recipients that such worms pull from your 
address book are STILL of no use to the worm UNLESS you are authorized [by 
them!] to send those people HTML, attachments, or encoded body text... and if 
you're like most senders, you don't need to send that stuff to most (maybe even 
ALL) of the people you write to.  This means that statistically, it's much less 
of a "sure thing" for the worm... maybe [hopefully!] to the point that the 
success/survival rate for such programs falls below 'critical mass' for 
meaningful propagation.

> A whitelist would have passed them right through in every case where the names 
intersected, 

That's precisely NOT the case using my "permissions" approach, and your 
statement shows why I don't think you understood the implications of what I'm 
proposing.

> and the odds of that, for any two names in a given address book, are probably 
pretty high... much higher than chance, anyway!

With my concept, if you're not a sender of HTML/attachments/encoding to your 
recipients (and presuming that they don't turn those features on for senders not 
requiring them), then *none* of the names in your address book would be 
productive... not to a spammer forging your "from" address, and not to a worm or 
virus attempting to send itself (ActiveX/scripting/attachments/etc) to addresses 
pulled from your address book.  NONE of those, sent either from YOUR system OR 
from some open relay, would end up being delivered.

Again, it IS true that sending plain ASCII text spam would still go through... 
but with those restrictions, spam is far less pernicious and dangerous, and FAR 
easier for content filters like SpamAssassin to identify and deal with.  
Together, I think we'd nail the great majority of it.

[And... it's not maybe necessary to prevent ALL of it... if the statistical 
'success rate' of spamming drops low 'enough' then maybe spammers will find it 
simply not worth it.]

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment!  Join at http://www.cauce.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
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg