Re: [Asrg] SICS

[Seth Breidbart <sethb at panix.com>]

gep2 at terabites.com wrote:

>> In order for it to eliminate zombies, it has to be implemented by
>>_everybody else_.  That's not going to happen.
>
> Well, yes and no.
>
> I agree that you probably won't eliminate 100% of the vulnerability, but at some 
> point the remainder doesn't much matter.  The issue is whether the vulnerability 
> is widespread enough to ATTEMPT to exploit it.

And that doesn't take much.

> It also depends on how quickly such a fine-grained permissions list
> approach is accepted and installed.  Obviously, if Microsoft were to
> include something like this in Outlook and Outlook Express by
> default, it would be much more effective and much sooner than if
> Infopoint or some other small software company were to try to market
> it as an addon package.

You mean 5 years instead of 20?

>> You're assuming that you can tell whether or not the _recipient's_ MUA
>> will attempt to interpret a message as HTML.
>
> It doesn't much matter.  Most spammers don't know, either, what specific E-mail 
> client program a destination address is using.  Nor do they care, in
> fact.  

Precisely.  The spammers will attack a vulnerability that affects only
a small percentage.  You have to defend against all such
vulnerabilities.

That issue is already known in virus protection.  Some email clients
were treating some messages as HTML that the anti-virus software
thought was (safe) plaintext.  The spammer didn't care _which_ victim
he got, just _how many_.

>> For some spammers, maybe.  Many others sell their services, and the
>> worldwide shortage of suckers is not expected soon.
>
> It won't take long for the word to get around that spamming doesn't work 
> anymore, and that some types work dramatically less well than others.

And some spammers will just think it's good that the market is less
crowded, and spam more.

>> Prove it.  Come up with a reasonable implementation that my mother can
>> handle.
>
> I'll be GLAD to do that, and I'll even bring it to release-ready, if
> you'll fund the development.  :-)

In other words, you're claiming something that doesn't exist and
offering no evidence.

> The point is that this is IMPLEMENTATION-DEPENDENT, and does not
> need to be part of a "best practices" advisory.  Some companies are
> hugely better at "human-engineering" software products than others
> are; given that, we don't have to concern ourselves HERE with the
> fact that some of them might not do a terrific job of it.

However, it's close to necessary to demonstrate that it's _possible_
to do an acceptably-good job.

> Again, though, I'll point out that once you default to "no
> attachments, no HTML" in E-mails from unlisted senders, you don't
> leave the spammers much room to evade much of anything, at least as
> far as their E-mail content goes.

As I've already pointed out, "no attachments, no HTML" isn't a
clear-cut decision, and spammers will take advantage of every
implementation difference of opinion.

>>> Sounds good, until the "spammer" can find a case (even just ONE)
>>> where the intended recipient actually WANTED the E-mail in question,
>>> and said user didn't feel they had in fact granted their ISP the
>>> 'right' to MIS-BLOCK mail that the user actually wanted.
>>
>> Then the ISP show the contract the user agreed to, and the law
>> granting it immunity.
>
> There are a LOT of contracts which judges end up NOT holding as
> enforceable.

That's because there are laws against such contracts.  In this case,
there is a federal law (in the US) specifically allowing the ISP to
make such decisions, and immunizing it for doing so.

>> Mail Service Providers are growing.  They don't have to provide
>> Internet access; some people prefer buying unbundled services.
>
> Many ISPs try (hard) to prevent their customers using other mail
> service providers.  Agreed that they are not likely to be totally
> successful at that.

I haven't heard of _any_ doing that.  Do you know of any who have
blocked the ports for SUBMIT, POP, etc.?

Seth



_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg