On Thu, 29 Apr 2004, Philip Miller <millenix(_at_)zemos(_dot_)net> wrote:
Gordon,
I'm just going to pick out a few little points here about how LMAP is
complementary to your permissions system. Note that I agree with the general
principles of least privilege for email senders.
Thanks! I'll reply with my comments on the items you've noted.
1. Reducing zombie population
Likewise, we HAVE to work on cutting down the ease of zombie recruitment,
and I believe that my attachments (and HTML!) permissions list idea
(basically a fine-resolution whitelist) is a *major* step in the right
direction there.
I agree with you here.
Thanks. I think this is simply the BIGGEST improvement that can be made the
FASTEST to solving this TERRIBLE problem.
This goal is very compatible with implementing an
LMAP system, because it means you have an authenticated ISP to send
(automated) complaints and abuse reports to, and if they're on the ball, the
user part will have been authenticated by them, so it becomes a matter of
economics for them to clean up their network, to reduce complaints or to
avoid black-listing because they are abusive to the Internet as a whole.
Well, sort of.
I wouldn't say it's "very compatible with"... the way I'd characterize it is
that WITHOUT a fine-resolution whitelist to block virtually all executable
attachments and other malicious E-mail content, that LMAP and its ilk are
fairly
useless (as, indeed, are most of these other ideas such as E-postage,
certificates, SPF, and the like)... simply because spambot zombies mean that
actual spammers never pay E-postage, generate hashcash, deal with stamps or
certificates, or deal with any of these other restrictions that supposedly are
being designed to put a crimp in their operations.
The question then becomes... once the permissions list solves the great
majority
of the zombie spambot problem, and removes most of the HTML deceptions, and
antispam content filters resolve most of the rest... how much of a problem
really still remains, and would it justify the time, hassle, and expense of
these more intrusive, controversial, and costly schemes?
As for finding the right person to complain to... I still send complaints to
the
various Nigerian/lottery spammer ISPs, and although I'm sure I'm not the only
person griping about it, and although CLEARLY there's no question about who is
hosting the fraudster's E-mail boxes, the same small number of ISPs keep
getting
implicated with disturbing regularity. So I'm less convinced than you seem to
be that flooding them with automated complaints and abuse reports really
accomplishes anything; it seems that their own defensive automated
abuse-report-discarders are just as efficient! :-(
Ultimately, most of these abuse reports and complaint letters (and the ISP's
automated responses to them) just make the "wasted bandwidth" problem worse
than
if the original objectionable material just went down a black hole.
2. Preventing forgeries getting you infected
Even if one of those familiar senders WERE to get zombie-ized, the fact
that suddenly they're not behaving (SOMETIMES!) the way I expect them to
behave is enough to cause the irregular mail to be zapped, EVEN THOUGH
the real stuff they still occasionally send me legitimately will still
sail through to me just the way it always has.
If one of your legitimate correspondents catches a virus, there are a couple
things that could happen. If they send you a mail directly, odds are it gets
blocked by your ACLs. But imagine that the virus instead forges all of the
N^2 combinations of To and From using the addresses in the infected users
address book. There a chance (however slim) that you have a common
acquaintance from whom you'll accept an email that will infect you.
First, basically *no* E-mails will infect me, simply because my preferred
E-mail
client doesn't encourage that to happen. But I've seen a lot of infection
mails
arrive here, and I've investigated them enough to see how other folks get
infected. :-)
The fact is that the great majority of people simply have no reason to EVER
whitelist ANYBODY to send them an EXE file type as an E-mail attachment; fewer
still would whitelist ANYBODY to send them a PIF file. Few people similarly
ever need to accept an encrypted ZIP file! Secondly, the likely overlap in the
E-mail address books (regarding people I'd be likely to whitelist to send EXEs)
is likely to be the null set, or pretty close to it.
And even THOSE people I'm not likely to accept unexpected/unsolicited
executables from. (Obviously, Outlook or whatever E-mail client wants to make
it VERY ominous-sounding before they let anyone turn these permissions on... so
people won't let themselves be hoodwinked or wheedled by a bogus E-mail that
tries to talk them into dropping their shields.)
So anyhow, I think that your scenario is VERY VERY farfetched.
Now add authentication back into the mix:
If the 'vulnerable from' happens to be in another domain, the message will
be rejected at the recipient edge MTA as forged.
...And that is a BIG "if". Especially now with Internet accesses concentrating
around a relatively small number of big players... Comcast, SWBELL, SBC, AOL,
etc etc. And in fact, that's a big reason why the "domain-approved authorized
mail server IP address" concept (regardless of which variant you're talking
about) is so terribly flawed (aside from the issue regarding personal domain
names, mailing lists, etc etc). There are literally MILLIONS of SBC users,
MILLIONS of Comcast users, close to ten million AOL users, etc etc. So someone
infecting an SBC or Comcast user's machine can forge any of a million or more
other addresses which will NOT be detected by these schemes as forged. And
that's true even if they originate the mail from one of hundreds of other mail
servers used elsewhere nationwide by that big ISP.
If it's in the same domain
as the already infected person, then the ISP should be authenticating it.
Some do, some don't. Again, SMTP authenticating becomes problematical when
people are using their own personal domain names, mailing lists, etc etc. Many
ISPs refuse to let people forward mail to their domain name supplier's mail
servers, etc.
Looks like a win-win proposition to me.
And if you ignore the folks who lose big, you'd almost be right.
3. Sending back bounces to legitimate senders telling them that they were
out of line.
I don't see any point of E-mailing back (to who? AS IF there were a real
return address!) and telling them what to do to get past my checks!!??
Riiiiiiiight. No, a big part of the whole key to this thing is that the
legitimate senders know that their current behavior is acceptable
(perhaps JUST!) and that they may run into problems if they stray too far
from that standard (and different recipients may have set their filters
With LMAP, this works better. You will have a validated return path to send
a bounce back to, even after the message has been delivered locally.
You're presuming (and this is NOT necessarily a valid presumption) that the
SMTP
and POP mail paths are parallel and coherent.
Not everybody uses the same outgoing mail path as they use for their incoming
mail path.
The other question is to decide if it even makes sense to try to send the
bounce. I'm not at all sure that it does.
Thus,
if one of your legitimate senders just steps over the line (maybe attaches a
JPG that's 1K over what would have been tolerated), they'll get a bounce
saying it wasn't delivered, rather than wondering why you never responded.
If they write me and inquire, I can probably tell them I didn't get it.
And remember that (depending on what they sent me) it's entirely possible that
the BOUNCE ITSELF will be filtered out by THEIR permission list, since it's
entirely possible that the 'mailbot' sending the bounce won't be whitelisted at
their end, either. :-)
(This can occur even today... let's say that they send me an E-mail which is
4.9Mb, and by the time the various Received: headers are added it JUST exceeds
a
5Mb maximum E-mail supported by my domain supplier. If they try to bounce it
back along with an explanatory header, chances are good that the ORIGINATING
E-mail inbox won't accept it, either. Or, they might already have 3.5Mb of
mail
queued there already, and doesn't have adequate room to hold the bounced mail.
Anyhow, you can't always guarantee that a bounce will be received.)
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