[Asrg] Re: HTML-burdened email

On 2007-01-27 19:43:23 -0600, gep2(_at_)terabites(_dot_)com wrote:

Subject: HTML-burdened email (Re: [Asrg] Re: bounces, 
and anti-spam principles)


Please don't answer mails from different people in different subthreads
in the same mail. Your mails are already too long, and an argument is
hard to follow if the answer the content of one mail is in the answer to
a different mail.

(1) I'm shopping at a major retailer's website and decide to sign up
for their newsletter.  What happens if the confirmation message uses
HTML content (not uncommon)?


Obviously, it SHOULD NOT use HTML content,


But it does. And if you're a small ISP or IT department and your users
can't get their newsletter, guess who they'll blame? You or the major
retailer? And what's more likely to change? The way you filter mail or
the way the major retailer sends their newsletter?

You can do that if you're the DoD. The DoD recently banned HTML and they
can get away with it, because almost everyone they exchange mail with
is more interested in talking to the DoD than the DoD is talking to
them. If the DoD doesn't get your mails, that's your problem, not
theirs.

for the simple reason that said retailer CAN NOT be certain that the
person asking to be on their newsletter list is able to handle (or
WANTS to receive) HTML-burdened mail messages.


He doesn't care. 99% of his prospective customers can handle it, and
they will be enticed by the pretty pictures. He can afford to lose 1%
(who are probably the more critical customers anyway).

Assuming that the confirmation and the newsletter come from the same
source, that is, which also is not always the case.


True, although if that is recognized as important to 
legitimate mailers, they can certainly correct such 
questionable behavior.


That "questionable behaviour" is pretty much standard, and there are
good reasons for it.

(3) My biggest customer is a giant corporation which requires its
employees to use Microsoft Outlook and to attach a vCard-like
signature to every email, using a background stationery and having an
image of the company's latest logo because they're engaged in a major
rebranding initiative.  Not surprisingly, they have massive turnover,
so the people there who send email to a variety of people at my
company changes every several weeks.  Who's responsible for upkeep of
all of those individual agreements to exhange HTML with each other?


Again, the recipient could presumably set up a "catch-all" 
whitelisting which would enable selected E-mail HTML 
features and selected attachment types from any user at a 
given company's domain.  For example, allow (hell, even 
REQUIRE) V-card attachments or JPGs for mail from that 
domain, but (for example) not allowing scripting, 
executable attachments, or ActiveX.


Yes, he could. But he doesn't want to. It's not his job to worry about
which types of content a certain user (which he not even know) might
send to him in the future.

The only way your techniques can work effectively is if 
you assume that
the recipient is getting very little spam.


I don't think it's particularly volume-sensitive... other 
than the fact, of course, that ANY system could 
conceivably be flooded by a sufficiently determined DoS 
attack.


It's a DoS attack on the user, not on the system. The user has to look
at the mails, decide whether they are legitimate, which of their
features he wants to accept from that sender (and whether "that sender"
means only that particular address, or the whole domain or something in
between).

Well, 50% of our users are being sent almost no spam.


Your users are very fortunate.


Nope. That's the normal distribution. Many users get almost no spam,
many get a an intermediate amount of spam and a few literally drown in
spam.

Perhaps they haven't had those E-mail addresses for very long, or
don't do much with them.

But that doesn't help with the guy getting sent 4000/day.  Or even
the hundreds getting 50 or more.


I don't see why my approach won't handle such cases with 
ease.


That guy has to scan through 4000 messages each day to check if there
wasn't one which he did want. Maybe not every day, but at least every
time he suspects that a mail might have been blocked.

Introductory E-mails should NOT automatically presume the desire or
willingness of the recipient to receive HTML-burdened E-mails.


But if all spam were indistinguishable from 
"introductory e-mails",
where are you then?


No worse than at present.


Depends on what you define as "better" and "worse". You will get less
spam (about 50% less, I would guess from looking through my spambox),
but you will also get less legitimate mail (I don't know how common HTML
mail is on average - that seems to vary a lot).

And BETTER, since the "no attachment, no HTML" default 
rule would seriously cripple zombie spambot army 
recruitment.


Only if it is widely adopted. Which it won't be, because the early
adopters will have to deal with severe problems.

The XBL, for example, is _extremely_ reliable at 
detecting compromised
end-user machines.  All by itself it will block 70-85% 
of all spam.


Fine.  But it also blocks LEGITIMATE mail coming from 
those machines, right?


There is no legitimate mail coming from those machines. Maybe a message
or two for every million messages being blocked. Probably less.

By it's very nature it doesn't list real MTAs (eg: ISP 
smarthosts).


What if the spam is sent through ths "smarthost"?  You 
might claim that's not being done today, but nothing 
prevents spammers from doing that.


Then there is an ISP to complain to and the ISP knows which of their
users has a compromised machine and can do somthing about it. If the ISP
doesn't do something about it, he may find that some may refuse to
accept mail from him or apply more stringent filters to it. But that
doesn't have anything to do with the XBL.

You are assuming that IP-based reputation is used in an all-or-nothing
way. It isn't. There is more than one list, and just because an IP
address is or isn't on a specific list doesn't mean that all mails from
this address are rejected or accepted. It is one criterion among many.

Subject: Re: [Asrg] Re: bounces, and anti-spam 
principles

[how users configure their whitelist rules]

The problem being that out of the 60,000 seats here, perhaps less
than 10 of them are able to competently configure a set of rules
like what you have.


That's a software implementation issue, not an inherent 
problem in the approach.  I envision a button to click 
on

                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I guess that's the main reason why your ideas aren't met with wild
enthusiasm here. You "envision" that this would be simple to build
and to use, but it's not even clear that you have even built a
prototype which you use yourself, much less deployed the system for
"ordinary users", which aren't quite sure what an "HTML mail" is, and
have never heard about an "ActiveX component".


I've built and have used portions of what I propose. 
Obviously it will work best if the proposed default rules 
are widely used.

As for "deploying it for ordinary users", I think I could 
make the same claim regarding all these DNS-based 
proposals that y'all are so fixated on.


No, absolutely not. Apart from not being fixated on "DNS-based
proposals" (if anything, I'm fixated on bayesian filtering), I see two
very important differences here: 

1) DNSBLs like Spamhaus' SBL+XBL aren't "proposals". They have been
operational for years and their strengths and weaknesses are well-known.

2) The user has absolutely nothing to do with them. I can simply enable
them on a system-wide basis and be confident that I will maybe have to
deal with one complaint every few years.

Again, good software implementation doesn't have to depend on users
understanding those details


I doubt that. In real life users get mails with "advanced features" all
the time and if they have to decide whether they can safely enable them
they need to understand them. I predict that the average user will
either have configured that system to accept anything from anybody
within a week or give up on email entirely.

I don't think where things fall on that particular 
equation are especially relevant to whether the approach 
would be a good one for more widespread adoption.  :-)


It is irrelevant whether it "would be good". User's simply won't adopt
it. Period. It will ask them questions they don't understand twenty
times a day, so they will resort to either clicking "yes" all the time
or "no" all the time. As a result they won't get the mail they want and
they will still get mail they don't want. In addition they will feel
dumb because they don't understand all those questions, and they will be
angry at the computer (it should handle that stuff without asking stupid
questions) and the IT staff or ISP (it's their job to handle that
stuff). A week later the system will be shut off again and the poor guy
who thought "it would be good" will be fired.

that simply says "allow E-mails like this from the same sender in
the future" and where the software will open the keyway JUST enough
to allow that type of message if seen again from that sender.


So Uncle Bob will see that a mail from Aunt Matilda was blocked
because it contained an "executable attachment". Since he wants to
get mail from Aunt Matilda (and Aunt Matilda is a nice lady, she
wouldn't send him anything bad, would she?) he clicks on "allow
E-mails like this from the same sender in the future". Oops!


Presumably he could tell from the rest of the content in 
the mail message that it really didn't look like E-mail 
from Aunt Matilda.


To do that he has to read it. What good is an anti-spam scheme which
requires me to read all my spam?

        hp

-- 
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | hjp(_at_)hjp(_dot_)at         |
__/   | http://www.hjp.at/ |    -- Sam in "Freefall"

signature.asc
Description: Digital signature

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg