On 2007-01-27 19:43:23 -0600, gep2 at terabites.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.at | __/ | http://www.hjp.at/ | -- Sam in "Freefall"
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Asrg mailing list Asrg at ietf.org https://www1.ietf.org/mailman/listinfo/asrg