Subject: Re: [Asrg] Re: whitelisting

From: [email-masked]
Date: Sat, 30 Apr 2005 03:23:52 +0000 (GMT)

>> That's an implementation issue, and a good software implementation 
> will shield users from those specific details.

> I agree that an implementation which provide ease of use and 
accessibility for users to have this level of finely grained control is 
a good thing. I do not think it will solve our problem any more than 
current solutions in edge filtering already provide. 

I think it WILL, because:

  1)  it will virtually eliminate E-mail as a successful vector for the 
transmission of worms and viruses (thus GREATLY reducing the ability to create 
spambot zombies);

  2)  it will make it harder to spoof URLs in phishing exploits;

  3)  it will GREATLY increase the efficacy of antispam content filters.

> The problem I am referring to is not, necessarily, that of the customer being 
delivered unsolicited mail 

"Unsolicited mail" is NOT automatically a bad thing... for example, if you're in 
the "customer relations" department for a consumer product manufacturer, the 
GREAT majority of what you're going to receive is from people you've never 
gotten E-mail from before.  (Likewise for people who hand out a lot of business 
cards and network vigorously!).  This is, in fact, the reason why "don't deliver 
mail from anyone that's not whitelisted" is not a reasonable solution.

But I don't *EVER* need to receive 160K PIF attachments, or decrypting 
Javascript E-mails, or unsolicited 5Mb .BMP files attachments, or most other 
kinds of HTML-burdened E-mails.

> ...but rather the support and operating costs it generates. I do not think the 
adoption rate of any application which requires consistent user interaction to 
derive effectiveness will be high enough to offset the costs necessary to reduce 
filtering in the core.

I don't think user interaction, if they SEE SIGNIFICANT PROGRESS, and feel like 
THEY ARE IN CONTROL, is a problem.

> If you find anything which meets your requirements, I would love to see 
it if for nothing else than personal use.

Well, one thought would be for me to simply write one (and I'm currently running 
here a somewhat different self-written incoming E-mail processing filter, 
written in protected-mode SPITBOL) but ultimately where my proposed filter WANTS 
to be is incorporated into Outlook Express and Outlook (and following which, in 
competing E-mail client software).  Nowadays, the problem isn't so much WRITING 
good software, but managing to get it distributed widely enough to be helpful.

That said, I'd be glad to write the software to run independently (i.e. to work 
with existing E-mail clients), if you know someone who would be interested in 
funding the effort... if you do, send 'em my way.

>> The point is that even (usually) well-managed systems CAN be infected, 
> and other
> users at the same ISP can often forge addresses for other users at the 
> same ISP domain name.

> Unless you are referring to the risk of an ISPs mail server itself 
becoming infected, 

It doesn't (not at all!) have to happen that way.

> ...you can mitigate this risk by ensuring that only authenticated users can 
send mail... 

No, because once their system becomes infected their machine can send spam using 
the user's valid "authentication".

That's a big reason why the whole SPF and "user authentication" approach simply 
is ill-conceived.  It doesn't solve the problem.

> ...and that authenticated users can only send mail with "from:" addresses 
matching their specific allowed addresses.

Likewise, that's completely ill-conceived.

First off, many users send "business" mail (or other mail using their 
personalized "vanity" domain names) through a differently-named (e.g. home) ISP.

Second, people travelling need to be able to deal with their E-mail (from their 
cruise ship Internet cafe, the business center in the hotel where they're 
staying, etc etc.) and it's stupid and a nonstarter to try to force them to not 
use their own E-mail address as the "From:" address.

Third, people sending mail from (for example) airport E-mail access kiosks have 
NO choice over which SMTP server will be used to send the mail messages.

Fourth, just making sure that the From: address domain corresponds to a mail 
server "authorized" to send mail for that domain name is hopelessly inadequate 
because major ISPs (swbell.net or whatever) could have literally MILLIONS of 
users and hundreds or thousands of "corresponding" mail servers... so ANYBODY 
sending through ANY of those could conceivably forge mails from ANY other 
customer connecting through that same ISP.

>> Therefore it allows eliminating the ugliness of "someday" and
> allows besieged recipients to get relief RIGHT AWAY.

> Your definition of "right away" and mine differ. 

Installing the software would result in an IMMEDIATE and SIGNIFICANT elimination 
(as seen by the installing recipient) of large classes of junk mails, including 
virtually all viruses and worms.  It would HUGELY improve the performance of 
their (perhaps existing) antispam content filter.

> Your solution still requires development...! 

Sure, I don't know of any solution that will write itself.

At least my solution CAN be written, doesn't break existing standards, and 
doesn't require worldwide consensus to be useful and effective.

> ...and cost incurred by promoting its adoption within 
our user base. 

That's the distribution issue I mentioned earlier.  Sure.  Software doesn't 
install itself (at least it SHOULD NOT, as a rule) and typically you WANT users 
to be (very) aware of the change to their incoming mail rules.

(If nothing else, you want them to KNOW what they've added so they'll RECOGNIZE 
AND APPRECIATE the difference once it's installed).

> It would be significantly sooner than waiting for 
adoption of all players in Internet mail to secure their mail servers 
and I look forward to seeing a mail client with this functionality.

I hope so.  I keep hounding my contacts in Microsoft... hopefully someday the 
message will get to someone in a position to do something about it.  But it's a 
big company, sigh.

>> Again, my approach offers MUCH greater nuance than that.  A trusted 
> friend who
> happens to be using a somewhat-flakey or sloppy ISP doesn't have to be
> penalized.  Your suggestion results in painting folks with too wide a 
> brush, which prevents effective filtering.

> I do not encourage sloppy or somewhat-flakey players in any space. 

Sure, but you may not have a lot of choice.  For example, in my area there are 
basically two 'reasonable' ways to get high-speed Internet connections to my 
home... DSL (invariably involving SBC... and I'm presently too far from their 
wiring center for DSL), or Comcast via cable connection.  The others are merely 
marketing subcontractors for those two, or else higher-priced 'commercial"-type 
suppliers.  In case you hadn't noticed, there's been a lot of consolidation in 
the field.  :-(

> Inconsistent mail service is a good reason to switch to a better 
network provider. I believe a more appropriate point would be that you 
do not wish to penalize your own subscribers by blocking legitimate 
mail received from friends on sloppy providers. 

The filtering needs to be COMPLETELY transparent to recipients so they can 
quickly go and see what has been quarantined.  The spam filters that one of my 
service providers used turned out to have SO many false positives (and thus 
quarantining a LOT of legitimate mail) that I finally (after fighting them for a 
while) just decided to turn theirs off completely and deal with the stuff here 
using my own tools and approaches.

[At least I *was* able to do that!]

> Unfortunately, not 
penalizing a subset of customers who receive mail from legitimate 
sources on sloppy providers often times penalizes are larger subset of 
customers who receive unsolicited mail from this same provider. 

That's why it's simply STUPID and ILL-CONCEIVED to make the decision based on 
where the mail (apparently) came from.  It's smarter to decide based on what the 
mail CONTAINS.

> And thus begins the magic juggling dance of blocking unsolicited mail while 
reducing false positives.

Again, there's nothing wrong with unsolicited mail.  I **want** unsolicited 
mail, as long as it's responsible... and even better if it's an inquiry from a 
potential new consulting client.  :-)

Meanwhile, there are a lot of types of incoming E-mails which contain content so 
clearly unwanted or egregious that I don't care if I *never* see it.

One example is any incoming E-mail message which contains (for example) a PIF 
attachment bigger than (say) 16K bytes.  I also don't need or want E-mails which 
contain obscured URLs in HTML links... those which (for example) store the 
entire server domain reference as a single huge integer, or which obscure the 
domain name by converting it to gratuitous hex references or some such.  
(Actually, I don't much care to EVER receive HTML-burdened E-mails, especially 
not on an unsolicited basis, but I realize that others are less upset about that 
wasteful stupidity than some of us folks are).

>> It leaves innocent victims who are punished by association.

> Encourage innocent victims to make better choices.

They may not have a lot of choices.

For another example, when you're traveling on business, how do you know what ISP 
is operating those airport Internet access kiosks?  Do you get to control who 
provides the service to your hotel's business center?

Sorry, but this "better choices" crap is simply unrealistic.

>> Fine.  Again, my approach allows a recipient to control what THEY 
> receive, and
> without leaving them in the frustrating position of "I wish someone 
> else would do <whatever>."

> This is akin to a thread I am currently participating in on NANOG. In 
cases where customers want to be in complete control of the traffic 
they receive, they should be willing and understand that this will be 
awarded at a higher price point and include maintaining their own mail 
infrastructure.

When the customer is accepting MORE of the burden of the processing, it's 
obnoxious for the ISP to try to charge them MORE for the privilege.

It's kind of like the cheap-ass ISPs who assign stupid miniscule 10Mb E-mail 
boxes and then bounce their customer's mail if their mailbox overflows, maybe 
just because they're off on a cruise or because their retrieval process bombed 
(power glitch at their home, maybe).  With disk space costing thirty to fifty 
cents a gigabyte, purchase price, and high-speed ISP service costing sixty to 
eighty dollars a month, it's ludicrous to force customers to undergo painful 
contortions because their ISP won't allow them to use (even on an exception 
basis) more than a penny's worth of hard disk space for mail storage.

I'd gladly set up my own mail infrastructure here (and in fact, I have it, 
except I can only use my own servers locally), other than that my cable 
connectivity provider won't let me set up my own servers and hook them to their 
service.

>> No, because the mail could be FULLY authenticated, if the victim's 
> machine has
> been infected by a spambot zombie.  That spambot could send E-mail 
> spams and worms using the REAL user's AUTHENTICATED permissions.

> Yes. Regardless of the content recognition you place on the receiving 
end, in this case you will receive some spam or have a higher rate of 
false positives.

No.

If a recipient has the (default) rule to not accept executable attachments from 
anybody (unless they're whitelisted, and most users simply in practice wouldn't 
whitelist anybody to send them executable content), then that should be 
basically 100% effective at blocking the E-mail transmission of viruses and 
worms.

I don't believe that it's NECESSARY to eliminate absolutely 100% of all spam 
messages.  I think it's probably enough to reduce the number of undetected 
incoming spam messages to a "very tolerable" level.

>> Even if they are, authenticated mail can still be fraudulent.

> Authenticated mail which does not match the finely grained controls, 
which could place undue burden on the sender to know those controls in 
advance, 

Oh, give me a break.

It's no big "burden" to expect a (especially first-time) sender to send plain 
ASCII text, and to not (abusively!) send HTML, attachments, or large E-mails to 
people unless they've previously contacted that recipient to confirm with that 
recipient that they consent to receive that kind of content, and from THAT 
sender.

It's simple courtesy.

> ...is going to be passed along in either case. When that happens, 
it is important to have authenticated sender schemes in place in order 
to respond to the appropriate party.

I don't think that "authenticated sender" schemes work for many folks, and in 
any case they CERTAINLY do not do much to eliminate or reduce spamming, or 
worms, or viruses.  Any spambot zombie can send "authenticated" spam.

"Authenticated sender" schemes are braindead, ill-conceived approaches which 
simply don't solve the problem.  Any time spent on promoting or installing them 
is probably time wasted that could better be spent on more productive 
directions.

>> It doesn't have to.  You only need to have individual recipients each 
> have a
> finite number of TRUSTED recipients (and the GREAT majority of senders 
> a given recipient receives mail from will NOT need to be whitelisted).

> Agreed. 

Finally.  :-)

> When you find a system like this which provides the finely 
grained control you want, pass it along. 

Again, I'd gladly write it if someone wants to fund the development, and help 
set up distribution for the finished product.  :-)  Send 'em my way.  (Drop by 
my Web site to see what other kinds of stuff I've already done... so this isn't 
a meaningless offer.)

> Mail clients have provided 
this for a long time in the form of accepting messages only from known 
senders. It doesn't have the finely grained control you desire, but it 
is an effective example. 

Bogus!!!  As you no doubt realize, the crude "accept messages only from known 
senders" simply isn't acceptable, so it gets disabled.  Please don't even try to 
equate a braindead and unusable approach which doesn't work, with a more nuanced 
and practical approach which WOULD.

> ...As in that case, I do not think it will prove effective in the long run as 
it requires too much interaction from the participant in spite of its high 
effectiveness rate.

How much interaction is required on the part of the recipient is a software 
design issue.  Good human-engineering can result in this being reduced to a VERY 
reasonable level.

Especially since the GREAT majority of legitimate E-mail, under my approach, 
would not require whitelisting (or other exceptional handling) at all.

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

---

From: Seth Breidbart <[email-masked]>
Date: Fri, 29 Apr 2005 23:52:24 -0400 (EDT)

[email-masked] wrote:

> "Unsolicited mail" is NOT automatically a bad thing... for example,
> if you're in the "customer relations" department for a consumer
> product manufacturer, the GREAT majority of what you're going to
> receive is from people you've never gotten E-mail from before.

That doesn't make it unsolicited.  If you asked for it (for instance,
you put on your web site "If you want to comment about our products,
send email to . . .") then it's solicited by definition.

Seth