Subject: RE: [Asrg] Introduction and another idea

From: [email-masked]
Date: Thu, 19 Jun 2003 16:58:17 -0500

>> Maintaining white lists for users in places other 
> than their computers raises privacy issues as 
> mentioned many times prior.

First, let me point out that traditional "whitelists" have a number of problems 
with them.  I think that many of those problems are mitigated by a 
PERMISSIONS-based whitelist such as I propose.

Specifically, people willing to send plain ASCII text without encoding or 
attachments (and without any HTML tags) would have their messages (by default, 
at least) go through without any problems at all.  This would enable those 
wishing to receive unsolicited messages (say, from consumers of a company's 
products, or from prospective new clients for my consulting services) to do so 
without any problems.

HTML, attachments, and encoded text HUGELY magnify not just the bulk and 
bandwidth of E-mail, but also create VASTLY increased risk and opportunity for 
obscuring mail content, malicious code, and other fraud and deception.  These 
features are simply not needed in basic E-mail (and that should include ALL 
unsolicited E-mail).  

Therefore, it makes sense in the "whitelist" to specify SPECIAL PRIVILEGES that 
are granted by a recipient to familiar, trusted, and justified senders of those 
kinds of costlier, riskier E-mail.  Those untrusted/unknown/unfamiliar senders 
who [ab]use these features without prearrangement to do that ought to find their 
E-mail bounced or even just simply discarded.

The GREAT majority of spam (and certainly the most 
dangerous/malicous/fraudulent), not to mention nearly all viruses and worms, are 
blocked virtually immediately by this simple, straightforward strategy... and 
one that can be implemented without major technological breakthrough or global 
re-engineering consensus.  Even better, most of the spam/fraud E-mail remaining 
can be rather readily dealt with using various content filters.

> As has also been mentioned many times in the past, the use of
"virtual" or "implicit" whitelists 

I don't like anything that precludes unannounced delivery of (ordinary, plain 
text) mail from unexpected senders.  Those mails can commonly include inquiries 
from potential new clients and customers.

> ...by means of using single-user
addresses or passing authentication tokens as part of messages 

Authentication tokens typically require special software provisions on the part 
of both the sender and the recipient.  It likewise requires coordination and 
agreements on methodology and techniques so that we don't end up with a 
crazy-quilt patchwork, which doesn't suit ANYBODY.

One nice thing about what I propose is that it can be implemented at the 
recipient ISP and is a single-ended system which doesn't require concurrence or 
adaptation by anybody else, other than merely sending unanticipated/unannounced 
E-mail in plain ASCII text (which should be the case, really, anyhow).

> can give the effect of whitelists while reducing significantly the privacy
issues. (since the whitelist is distributed, it is harder to
reconstruct.)

The whitelist I propose NEVER needs to be sent to anybody, other than (if the 
restriction is done at the ISP or domain provider, which has the advantage of 
truncating the spam sooner in the delivery chain) only just the point where the 
filtering is done.  I don't think that the sender should be told by any 
automatic means what their permissions are (other than unacceptable mail MAYBE 
being bounced) and CERTAINLY nobody should be able to retrieve a copy of the 
ISP/domain provider's overall permissions list.  Another advantage of my 
approach is that there is NO NEED to make any of that information available to 
anybody else.

> When discussing "whitelisting" we should not confuse the
mechanism with the concept. The concept is that some subset of the
entire universe of senders is given preferred access to an inbox. 

Up to that point, at least, my approach matches your definition of "whitelist" 
as a concept...

> This can either be by checking against an explicit whitelist which is
represented as a monolithic list of senders and privledges or it can be
done algorithmically by checking properties of the sent message (i.e.
tokens in headers or in addresses) to determine if the sender is on an
"implicit" or "virtual" whitelist.

I don't like that sort of approach because it means that senders must make 
special provisions to send to specific users, leading either to the "crazy 
quilt" patchwork thing I mentioned before... or to the need for some kind of 
global agreement for some new kind of E-mail, which will inevitably break many 
currently operating (legitimate) senders.

I'd like to see the permissions be changeable by the recipient at any time, 
besides, and that speaks against a token they'd deliver to an "approved sender" 
should that previously trusted sender betray that trust.

It's really rather like using an answering machine to screen your calls... where 
the sender calls and presents their case, and the recipient can listen silently 
and decide whether or not (based on caller ID, perhaps, and the message format 
and content) they wish to pick up and accept the message.

The GREAT majority of techniques used by spammers to obscure, defraud, mislead, 
deceive, and confuse are based on tricks of HTML, attachments, and encoding, 
including message-as-text, tricked-up obscured URLs, bogus HTML tags in the 
middle of words, misleading links, teeny 1-point text the same color as the 
background, and other such nonsense.  Denying them *all* of those techniques in 
one fell swoop will deliver a _serious_ blow to spammers and fraudsters, at a 
minimum cost (indeed, at a considerable BENEFIT) to both legitimate users and 
ISPs.

And the availability of the "whitelist" still allows (by prearranged agreement) 
any trusted sender to continue to send any of those features in their E-mail to 
willing recipients.

I *really* do believe that this offers the best combination I've seen of safety, 
effectiveness, and low cost (implementation/operating) of any approach I've seen 
to date.

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 19 Jun 2003 17:01:44 -0600 (MDT)

> From: [email-masked]

> ...

That's a very good way to make point.

People sendng strangers any sort of unsolicited email that involves
anything except plaintext ASCII are demonstrating either a severe lack
of clues or politeness or that the languages they share with the
recipient do not include any European languages.  For obligate English
speakers, either can be a good reason to discard mail unread.

(Note the "can be a good reason."  It won't be a good reason for
some situations.)

>E-mail bounced or even just simply discarded.

Yes!

(Could you adjust your line length to less than 78?  My ancient MUA
doesn't rewrap lines, and I think it shouldn't.  I control my own line 
lengths by piping paragraphs through `fmt` as I edit them with `vi`.)

> ...
> recipient ISP ...

Yes, but until ISPs can tell users who complain "run the Netscape or
Microsoft auto-update mechanism", they will not and cannot do such
filtering by default.

    ]]]]]]]]]]]]]]]]]]]]]]]]]]

] From: [email-masked]

] ...
] > Someone earlier suggested that free DNS systems such as dyndns.org would 
] provide RMX functionality for such cases.
]
] Yes, but as I understand it they won't do much if anything for those of us who 
] are still behind NAT and router, since domain names mapping to a nonroutable 
] 192.168.n.n address seem pretty pointless... am I wrong?  :-)

I'm sorry, but you are wrong.  Today "NAT" boxes usually include port
mapping.  You configure such a box to rewrite and forward incoming
packets for TCP port 25 to some port at one of your RFC 1918 addresses.
NAT is a great evil, but it can be made to handle a few cases including
FTP and SMTP servers.

The only significant problems with using an SMTP server behind a NAT
box on a dynamic IP address are that:

  - dynamic DNS does not work very well when your address not only
     can change but does change and if your definition of "work
     very well" is what might be called "professional grade"

  - your dynamic IP address is likely to be ratted out to blacklists
     of dynamic address by its reverse DNS name or your ISP.

Vernon Schryver    [email-masked]

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 20 Jun 2003 12:09:32 -0400

> Authentication tokens typically require special software
> provisions on the part of both the sender and the recipient.
	You're new to the list and thus have probably missed some of the
earlier discussion. While authentication tokens *typically* require
software support at both sender and receiver, there is a class of them
that only requires software support on the receiver side. These are the
"single user" addresses. I might, for instance, create an address that
authorized you to send me mail. Such an address would look something
like: "[email-masked]". The "token" part of this address would
be a hash of your "From:" address. With such an address, you don't need
any software on your side to pass the token.

> The whitelist I propose NEVER needs to be sent to anybody,
> ... only just the point where the filtering is done.
	Even if never sent to anyone, there is still a privacy concern
with whitelists since if they are explicit lists, they provide a single
list of all of your correspondents. In many cases, people will feel that
compiling such a list is a risk to their privacy since such a list would
be open to inspection by government agencies under some circumstances
and to employees of an ISP if the list is maintained remotely. Even if
only maintained on your personal machine, it could be embarrassing if
people with physical access to your machine could discover the full
universe of your correspondents.

	For more information on "single user" addresses or other
mechanisms to pass tokens with software support on only one side of the
exchange, see my comments in: 
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg05395.
html

		bob wyman