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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg