Subject: Re: [Asrg] "more readable"

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 22 Jun 2003 00:27:13 -0400

At 08:54 PM 6/21/2003 -0500, [email-masked] wrote:

>On Sat, 21 Jun 2003, Kee Hinckley <[email-masked]> wrote:
> >At 6:12 PM -0500 6/20/03, [email-masked] wrote:
> >>I think you ought to let the READER be the judge of what the READER 
> finds the
> >>most readable... based on THEIR screen, THEIR vision, THEIR color 
> preferences,
> >>THEIR screen resolution, etc etc.
> >
> >This battle was fought and lost with HTML web sites.  Why do you
> >think you'll have any more luck winning it with email?
>[..]
>
> >And all to bring about a change that spammers can adapt to in less
> >than a week.
>
>Changing to plain ASCII text E-mail will get the mail past THAT level, but it
>will (again) deny them the great majority of their most cherished tricks, AND
>make their stuff more readily filtered by content filters.  It makes it 
>harder
>for spammers to confuse, deceive, and trick their victims.  So even when
>spammers "adapt", they _never_ get back to what they had before.

Keep in mind that while you reducing these things, nevertheless in the end 
of the day there is still the same number of emails in the user's email inbox.

>  [..] What we're trying to do is to put a crimp in
>their gears, and to make life more difficult for spammers and abusers.
>
>As for those who seem so determined to prevent that from happening... one 
>has to
>wonder what their true agenda actually is, and whose side they're on.
>[..]

There is no reason to get personal, we are all fighting the same enemy and 
are all on the same side.

Yakov  

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Sun, 22 Jun 2003 02:42:06 -0500

>of the day there is still the same number of emails in the user's email inbox.

Again, I disagree.

First, the fact that spammers wouldn't be able to do "text as image" (etc) means 
that content scanners can be significantly more effective, catching a (much) 
higher percentage of spam.

Second, the fact that the resulting spam is less likely to produce "success" for 
the spammers probably will make a lot of today's spam no longer interesting for 
the spammers economically.  I expect that to reduce the quantity of spams (or at 
least reduce the growth rate!), too.

>There is no reason to get personal, 

I didn't name any names.  But if the shoe fits....

> ...we are all fighting the same enemy and are all on the same side.

If EVERYONE was on the same side, spam wouldn't be the problem it is.  It's 
already been pointed out that spammers seem to be among the participants 
(lurking, at least) here... it's not a terribly hard leap to imagine that not 
all of them are passive lurkers, and that some of them are trying to create 
confusion, discord, and to try to block or delay any kind of positive outcome 
that would seriously impact their business.

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment!  Join at http://www.cauce.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.

---

From: [email-masked]
Date: Sun, 22 Jun 2003 11:55:35 -0500

>>>HTML is not, and has never been, a precise or deterministic page layout

>>>Fax by its nature is an IMAGE.  HTML is NOT an image, nor is it a page

>>>They can do that using Adobe Acrobat, Word, TeX, and various other 
>>kinds of page composition languages.  HTML is NOT like any of those.

>>Quite right.  There are all perfectly valid technical arguments.  And 
>of course those tools are all available to users.  Why do you suppose 
>they use HTML instead?  It's the easiest tool.  It's builtin to the 
>mail program.  So they use it.  They don't care whether it sends 
>html, postscript or word underneath.  It's what they have.

Generally, they don't have the slightest clue what the implications are of 
turning the feature on, in part because THEIR E-mail program hides the extra 
bulk and "ugliness" from them.  While in some situations, software SHOULD hide 
the 'inner workings'... there's also the danger that sometimes (as in this case) 
one gets an arrogance based on ignorance... rather like Marie Antoinette, who 
was so insulated from the day-to-day issues her subjects endured that when told 
they had no bread, cavalierly and in ignorance replied, "let them eat cake!"

Anyhow, it's one thing to REALIZE AND UNDERSTAND that many users are ignorant.  
It's another thing to go out of our way to continue and nurture that ignorance.

Personally, I think that most users are educable.  We ought to give them the 
information they need to make good choices.

But in EITHER case, it's not at all unreasonable to offer the tools to the less 
ignorant to protect them from the carelessness and thoughtlessness of the more 
ignorant.

[E-mail as opposed to Web sites]

>>not ONLY about what just ONE of them wants.  To be useful, it must 
>>be useful and
>>correspond with the needs and wishes of BOTH of those parties.

>That would be nice, but it is by no means a requirement.

Sure, but there's likewise NO requirement that the recipient has to read or 
listen to a sender or speaker, either.  They need to have the right (and tools) 
to allow them to simply "turn off" the offending speaker or sender.

>>That is not a key part of my proposal, although if it's only just a matter of
>>destination/origin name pairs I would suggest that "keeping track" of every
>>correspondent you've exchanged mail with represents a terribly small 
>>database by
>>today's standards (and that doesn't necessarily need to be on your 
>>own machine,
>>it could well be at your ISP or domain provider).

>And when I change ISPs and everyone's email to me bounces?

First off, only mail violating your stated permissions bounces (as it should).

Presumably your system could maintain (or download) a (local copy?) list of your 
own permissions for each of your known/trusted senders.  When moving to a new 
ISP, presuming that they offer a similar permissions list feature, you could 
upload your permissions list to "seed" the new ISP's filters.  Of course, if the 
new ISP doesn't offer such a feature, you'll probably start getting more and 
larger spam/viruses/trojans again.  :-((

>Or when RIAA comes calling and asks for a list of everyone I may have 
>sent an MP3 to?  

Anybody can ask for anything they like.  Doesn't mean you have to give it to 
them.  

If they get a court order allowing them to seize and examine your computer 
(and/or the mail logs from your ISP) then there's probably a lot more evidence 
of any guilt (or innocence) than just your mail permissions.  (So that's really 
a bogus point.)

...(which probably wouldn't indicate, anyhow, what TYPE of attachments you'd 
allowed!  although one could certainly imagine a proposed extension to the 
permissions list where one could specify that a given sender could send only 
certain ALLOWED attachment extensions... say, GIF/JPG only... and that 
executable extension types attachments could only be received from an even 
smaller subset of your corresponding senders.)

> No thank you.  I'd rather have the spam.

That should certainly be one of the choices open to you, as the recipient.

Honeypot mailboxes, for example, will want to receive EVERY spam message they 
can.

>>I think that just about everything we have been proposing represents at least
>>SOME kind of change, AT LEAST at the ISP level.  One big advantage of what I
>>propose is that it can be implemented at a *single* ISP (indeed, even at a
>>single *recipient*) and virtually immediately yield a very substantial
>>improvement.

>Read the example scenario someone gave to your proposal.  

I haven't seen it yet (I'm running digest mode on this list), but I'm sure I 
will.  But I'll go ahead and respond to it here.

>You mother bounces email from your aunt.  

First of all, since she presumably has had an ongoing correspondence with the 
aunt, she probably already has the appropriate permissions set, so that the 
aunt's mail doesn't bounce.

>The mail to your aunt (with the latest 
>pictures of the grandkids) didn't get through.  The instructions tell 
>her not to send HTML the first time.  She doesn't know what that 
>means (trust me, I've tried to explain the situation to *lots* of 
>email users).  

If the accompanying instructions (whether in the return E-mail, or in the 
suggested Web site it contains a URL pointer to) is good enough, then most 
people will be able to understand and deal with the problem.

> She calls up your mother.  She can't help, 

But she CAN, since if aunt calls mother, it would be a SIMPLE matter for mother 
to set aunt's permissions to allow sending mother the desired attachment.  End 
of problem... simple, quick, straightforward.  

>she calls her ISP.  Her ISP explains the problem, she tells them to stop 
>blocking HTML.  You've increased customer support costs, and haven't 
>reduced spam.

Talk about a leap of logic.

Permissions lists are CERTAINLY not going to be routinely maintained by 
telephone calls to customer support at the ISP.  

You're talking about costs to the ISP, and I'll point out that *none* of the 
proposals I've seen here (spf, et al)... other than mine... have been about 
significantly reducing overall bandwidth costs to the ISP.  What everyone seems 
to think appropriate is adding additional layers of overhead to SMTP, DNS, etc 
etc.  which ONLY increases total bandwidth used.  

Besides, as I think I've made VERY obvious, spam will be DRAMATICALLY reduced 
(at least relative to without it!) by use of my permissions list... certainly in 
terms of bytes per spam (if they abandon use of HTML and associated tricks and 
attachments).  Probably in count as well (deliveries, even if not sendings).  
And in the case where spammers do NOT stop sending HTML-burdened spam, then the 
permissions list ends up either bouncing or t-canning virtually ALL of it.

There is virtually NO rational argument for a situation where the permissions 
list approach would not DRAMATICALLY reduce spam.  Count, or aggregate bytes, 
and probably both.  As a side benefit, the permissions list approach would take 
a HUGE bite out of viruses/worms/trojans, too... which spf et al would almost 
CERTAINLY not achieve.

>Stop thinking bits and networks.  Starting thinking real people on 
>real machines with real customer support problems.  Your solution is 
>not feasible in the real world.

I disagree.  And I've been thinking about "real world" users and problems (and 
solving those problems!) in this business for more than thirty years.

>Viruses were spread before HTML email.  

Right, mostly by attachments (and before that, mostly by bootable floppies or 
infected executables).  HTML (along with ActiveX and such) has merely added a 
further danger.

>Spam was spread before HTML email.  

Right, but HTML has made it FAR more insidious.

I don't think ANYBODY can with a straight face pretend that HTML hasn't been 
increasingly employed by spammers to "trick up" their E-mails to try to evade or 
confuse filters put up to try to defend against it (as well as to try to 
obfuscate the guilty parties, to try to make it harder for most recipients to 
know who they should send their complaints to.)

Even so, I'm not proposing that we ELIMINATE HTML-burdened E-mail (as much as 
many of us more-technical-types might like to see that happen).  I'm saying that 
we should give users the tools to allow them to block its use by UNTRUSTED and 
UNKNOWN senders.  This would undeniably block a GREAT deal of spam, and reduce 
significantly the costs associated with the remainder.

>You offer absolutely no evidence that convinces that removing 
>HTML email would have any impact at all on spammers.  

I'll comment that NOBODY here has offered "proof" that ANYTHING that's been 
proposed here would have "any impact at all" on spammers.

However, I think that there is (even in the absence of "proof") widespread 
agreement among most of us on this list that spammers would either:

  * revert to sending plain ASCII text E-mails (reducing spam size by typically 
70% or more, and making it more readily identifiable by content filtering)

or

  * continue sending HTML-burdened E-mail regardless, in which case it would be 
mostly or entirely blocked due to coming from an "unapproved/unknown/untrusted" 
(on a recipient-by-recipient basis) sender of HTML-burdened E-mails.

I don't see ANY POSSIBLE scenario in which such a "permissions list" approach 
would NOT have an on spammers, their techniques and their methods.  If you CAN 
imagine such a scenario, perhaps you'll share it with us.  :-)

>Would they stop 
>earning money all of a sudden because the spam was plain text?  

It is virtually certain that spam would become less productive for them.  The 
tricks they use to evade filtering and confuse recipients would largely be 
denied to them.  It remains to be seen HOW MUCH less productive spamming will 
have to be in order for many spammers to decide it's not worth it.  

I don't think there's likely to be a single "silver bullet" (or "wooden stake") 
which will put an end to spamming by itself.  It's more likely that Net-employed 
things like my proposed permissions list, combined with some high-profile 
anti-spam wins in the courts, combined with more decisive legislation by the 
relevant jurisdictions, and probably other measures, will all combine to tighten 
the noose around the necks of spammers.  Eventually, more and more of them will 
drop out and decide to take up other professions.

>Would it put them out of business?  $5-6000 a week people were earning on 
>the Iraqi card spam.  

There's a lot of money earned in all manner of illicit professions.  I don't 
think we're going to eliminate organized crime here overnight, either.

>The vast majority of spam you receive has HTML 
>tricks in it to fool the spam filters--not the reader.  

I can send you plenty of examples of other types, if you really want.  But I'm 
sure you've seen them too.

Among them are frauds attempting to steal personal information related to E-bay 
and PayPal accounts by techniques including obfuscated URLs of the sort such as:

 http://www.paypal.com@%nn%nn%nn.%nn%nn%nn%nn%nn.%nn%nn%nn/bogus/stealdata.htm

Presumably, well-written spam filters wouldn't be deceived into thinking that 
paypal was the actual server being connected to.  Those techniques are designed 
to fool the casual observer who DOES take the trouble to look at the actual HTML 
being received, and who doesn't understand what the "@" means.

Other sorts of things include stuff like:

 <a href="http://123.123.123.123/fraud.html">www.ebay.com</a>

I don't know why we even have to discuss stuff like this here.  Most of the 
readers on this list ought to have seen more than enough of these kinds of 
things to understand the problem, and to realize that HTML is a BIG part of the 
problem.

>The fact that the content is HTML is irrelevant.  

ABSOLUTELY *NOT* true.

>Do you really think the average 
>user is going to realize that 
>http://[email-masked]/foo.html isn't Microsoft, just 
>because they now have to cut and paste it?  

Perhaps not, but at least it gives them the opportunity to LOOK at it, which 
they usually now don't really have.  Clueless users tend to "just click" on 
links and have no idea of what they just did, or where they went.

Each of these things make a little difference.  Together, they can make a BIG 
difference.

>You've shown no benefit, 

Rubbish.

I think that the benefit is substantial and UNDENIABLE.

Probably a BETTER return on investment than ANYTHING else that has been 
discussed here, in fact.

>and substantial software rewrite 

Which software are you talking about that you think would have to be 
"rewritten"?

Indeed, I think that one of the ADVANTAGES of the "permission list" approach is 
that it would have almost NO _requirements_ on "rewriting" basically anything 
else.  The whole point of the permissions lists is that recipients can opt to 
continue receiving ANYTHING AT ALL that they receive at present, with NO changes 
at all required by senders OR in the main E-mail software used by the 
recipients.  (The default, I feel, ought to be 'locked down' in any case.)

Recipients could employ the new spam-and-worm-blocking powers to any degree they 
wished, or not at all.  Their choice.  (Personally, I think that most recipients 
are pissed off enough about spamming that they'll choose to use the filtering 
with a vengeance...)  But we would find out, anyhow, what the percentages are, 
after a few weeks/months/years of having such a system in place.

I *would* hope that AOL and Microsoft would both eventually see the wisdom in 
ceasing the pointless and hugely wasteful sending of HTML-burdened E-mails by 
default.  But the 'permissions list' approach still works fine, even if they 
don't.

>and customer support costs.  

There are substantial "customer support costs" due to spamming, too.  Our goal 
is to reduce the spamming plague.

There will probably be a spike of customer support issues at the BEGINNING of a 
'permissions list' approach, sure.  To some degree, that's inevitable (and will 
probably be true for ANY change we propose AT ALL).  The difference is that it 
will be a SPIKE and people will figure it out, whereas the customer support 
issues regarding spam are otherwise ongoing, and (worse) growing.

>Make a real proposal with real numbers, then it's worth discussing.  

Why are you trying to hold my proposal to a higher standard than any of the 
other proposals discussed here?  Or are they not "worth discussing" here either?

Anyhow, sorry... I don't agree.

>Better yet--convince a single ISP to try it.  

Sounds good to me.  I don't know which if any of them might have folks lurking 
(or participating!) here.  I'd be glad to offer my consulting services to any of 
them, though, who might feel that this would be worth trying (although the idea 
isn't so complicated that most of them couldn't probably implement it easily 
enough with existing inhouse staff).  It's possible that we could "bluesky" 
interesting and worthwhile side things, such as good ways to maintain the 
permissions lists or something.

> Nobody is going to propose it as a standard until it's been proven in action.

  1)  My idea doesn't NEED to be proposed or made "a standard" in order to be 
useful.  That's one of its BIG advantages, in fact... it doesn't REQUIRE a 
network-wide consensus, the way spf and some (many!) other proposals do.

  2)  If something DOES require "a standard" in order to "be proven in action", 
and nobody will propose it as "a standard" until it has been, then it sounds to 
me like we've set up a chicken-and-egg situation which isn't going to get us 
anywhere.

I really do wonder if some of the folks here aren't here with the primary goal 
of tossing spanners into the gearworks of any approach which could make a real 
difference regarding spam.

But getting back to the earlier point, I don't think there's ANY plausible case 
to be made for the contention that widespread adoption of such a "permissions 
list" approach would be totally ignored by spammers, and that it wouldn't have a 
SIGNIFICANT (and negative to them) impact on how they ply their trade.

I think it is similarly damned difficult to make a plausible case for the 
contention that the result (whichever way the spammers move) wouldn't 
significantly reduce spam mail volume.

---

From: [email-masked]
Date: Mon, 23 Jun 2003 01:10:33 -0500

>>If I had wanted my words quoted on ASRG, I would have cc'd ASRG. 
>That was a message sent directly to you.  As is this.  Have the 
>courtesy to treat it as such.

I'm not interested in having private off-list discussions on this topic, unless 
there is some specific reason for sensitivity requiring that privacy.  My time 
is valuable enough that I'm not going to waste it in one-on-one messaging with 
people who probably aren't interested in my ideas to begin with.  The people I'm 
trying to reach with my ideas are those who might be interested in actually 
making use of them, not those just interested in wasting my time.  Accordingly, 
unless you get an agreement with me otherwise, please expect this discussion to 
take place here.

>Wonderful in theory.  But they "give them lots of options" solution 
>does not work in the real world.

In practice, I think that most users will probably want and use a few 
straightforward options.  That's why, for starters, I think the idea of giving 
them the choices of HTML (yes/no), Attachments (yes/no), and Encoding (yes/no) 
are a good start. As we have discussed, there are various more detailed options 
available from there (sublevels of HTML, types of attachments, etc) which could 
be made available for users desiring that added control.

There could be another option, which would be spam content filtering (yes/no), 
also based on whether the recipient is 'known' or not, which would also allow an 
ISP to use filtering for mail from unknown/untrusted senders but would largely 
eliminate the problems of false positives in mail from trusted (and named) 
senders.  While some degree of content filtering could probably be offered at 
the ISP, I've tended to think that content filtering is generally better done at 
the recipient end, where choices can be made more readily... although lately 
I've started thinking that (especially in conjunction with my permission-list 
concept) there might be a place for at least some of that at the ISP level 
(perhaps in addition to local recipient-level content filtering).

>This is when you start waving your hands.  

That's because this is where individual implementation design decisions enter 
into the way things might work.  There's no need (and in fact, perhaps the 
opposite is true) to establish fixed one-size-fits-all characteristics and 
operating details.

>You claimed your solution was simple.  Here is clear proof that it isn't.  

I disagree.

>Stop making vague 
>assertions and sit down and figure out what it will take to make your 
>solution as easy to use as the current email system (or at least 
>within an order of magnitude).  Write it up.  *Then* see if anyone 
>buys your solution.

I'll be glad to do a more detailed system design spec and more detailed 
implementation proposals for someone interested in funding the work.

Sorry, I'm not interested in furnishing elaborate and DETAILED blueprints for 
free.  I have other demands on my time too, and bills to pay.  Many of those of 
you on salary probably have the luxury to do things differently.  As it is, I've 
been taking a lot of time I could be spending in other areas to try to 
contribute to the discussion here.

>Excuse me?  Where have you been for the past 10 years?  On the 
>contrary.  Your ISP is required by law to provide the information. 
>Just ask Verizon.

They CAN be required to furnish information.  In the Verizon case, it was in 
response to a court order, and followed an appeal.  In this particular case 
under discussion, that of my proposed permissions list (sender/addressee address 
pairs, and permitted attachment types for each pair) there's nothing really 
there which isn't already present (or which couldn't be inferred) by the 
incoming and outgoing mail logs already kept by the ISP (and yeah, I know that 
some countries are more or less demaning about how long those logs must be 
kept).  If the courts take a HARD interest in what you've done online, they can 
get a search warrant to seize and search your computer(s), too.  Which would 
give them A GREAT DEAL MORE INFORMATION about your activities online, so I don't 
see the permissions list as a major loss of privacy, presuming that the ISP is 
as responsible with it as they already presumably are with mail logs etc.

>But your ISP doesn't have to, and almost certainly does not, keep a 
>copy of your email logs.  Your system *requires* keeping information.

No, not a copy of your E-mails, but they most likely keep a copy of their mail 
server logs (messages in, messages delivered, from/to/IP, etc).

>Would it?  I don't know.  You haven't provided a specification.

Sorry about that.  Again, detailed blueprints require some work, and that's 
usually not free.

>Every correspondence has to start somewhere.  They can't all be 
>pre-existing.  Your mother gives your aunt her email address over the 
>phone.  Three months later the aunt gets email and sends her a 
>message.  Pretty typical scenario.

Yup, no problem.

>That's very easy for you to say.  (And I see a wonderful opportunity 
>here for spammers to fake these messages, but that's an aside.)  I've 
>had to explain this kind of thing to non-technical users.  Have you? 

Of course.  As a computer consultant, I deal with users all the time, at all 
levels of technical expertise from guru to appalling ignorance.

>...Furthermore, they are not going to see the need. 

Every Internet user I've spoken with understands that spam is a problem, and 
wants to see something done about it.

>Here, let me give you a typical (and I mean typical, I get these all 
>the time) customer support call based on your system.

>Hello?
>Yes, I can't send email.
>I see.  What did it say?
>It said it couldn't send the mail.
>I see. What said it?
>The message I got back.
>I see. Do you have a copy of the message?
>No, I deleted it.
>Who were you sending email to?
>[email-masked]
>Can you send email to anyone else?
>I don't know
>..

ANY system which results in blocking unwanted or unapproved types of mails (spf, 
contents scanning, whatever) will result (at least initially) in questions about 
what happened and why.

It will be **far** more easy to explain to users that "you sent an attachment, 
and your intended recipient hasn't (yet?) set their E-mail permissions to allow 
your E-mail address to send them attachments" than to try to explain to them 
more esoteric stuff about reverse DNS lookups and unsecured mail relays and the 
techhie stuff of the sort that other proposals discussed here have been based 
upon.  The system I proposed works FAR more in tune with things that (even 
unsophisticated) end-users are likely to be able to understand (perhaps after 
some educational process and familiarization, but to some degree that's 
inevitable no matter WHAT we come up with).

>I'm not kidding.  That's how customer support goes.  They don't 
>*read* the error messages.  It's all magic.  It's all confusing. 
>They have no idea which parts are important and which are not.  They 
>don't know what to ignore.  Writing software for the average user is 
>incredibly difficult.  You and I, we're used to things.  When 
>something goes wrong, we know in a second what to look at.  We know 
>which part of the message is important, which should be ignored. 
>Most people have absolutely no idea.

I agree with you that the design of the system needs to be designed to be as 
user-friendly as possible, but I don't believe that's impossible (or even 
terribly difficult, actually) to do.

>When you've presented the design of the software, and how it's going 
>to be implemented by the dozens of email clients on different 
>platforms.  Then I can decide if you are right.  

I've already proposed one example a few messages ago about one (possibly 
multi-level) transition scenario.  See the archives if you missed it.

>But the burden of proof is on your side.  

I don't expect to get everyone (100.00%) to agree (on ANYTHING).  That's like 
herding cats.  My hopes are that SOME will be interested enough by my ideas that 
they'll give 'em some serious thought, and hopefully see the value in them.  I'd 
be glad to elaborate them further (hopefully in response to a specific and 
suitably funded project) and even perhaps proceed to software development, 
systems integration, and installation/documentation/training etc should someone 
be that interested.

> To me, it looks hard.  

I disagree.

>Start at the very 
>beginning.  Who is going to tell her about the bounce and all those 
>rules.  

Go back to the archives and review my recent post about one or two proposed 
transition-period approaches.

>She installs the latest version of Outlook Express and it 
>suddenly starts doing this.  How does she know about it?  Do you 
>think she reads the readme file?

Presumably she will read the E-mail in her inbox.

>Actually, Barry wants bulk mailers (spam or otherwise) to pay the ISP 
>for their email delivery.  

I don't think that's going to fly, if for no other reason than free non-profit 
community-of-interest mailing lists (such as Yahoogroups et al).

Originally, the argument made for offering outWATS service was that something 
like 80-90% of the cost of long distance telephone calls was the cost of billing 
you for them.  Supposedly, as the argument went at the time (back in mid-late 
1970's) the telcos were going to just disconnect all the billing and accounting 
stuff from those outgoing WATS lines and pass the cost savings on to flat-rate 
callers.  Somehow that fell through the cracks (until just recently, when we're 
finally getting around to a few companies planning to offer actual "free" 
nationwide long distance to residential customers for a flat monthly charge.)

Anyhow, this is another case like that... where the complexity and costs added 
due to the accounting and charging scheme have to ultimately be borne by 
SOMEBODY and the resulting system isn't likely to please much of anybody, and 
probably be a lot worse than what it replaced.

>I have a friend at one of the legit mail 
>houses, and she went around to a number of ISPs seeing if they liked 
>that idea--none of them did.

Of course not.  I don't think most users would be happy about it, either.

>But ask Barry if he thinks changing messages from HTML to text is 
>going to solve his problem.  

I don't think that it is by itself a magic bullet, no.  I do think, however, 
that (along with control over unexpected attachments, and possibly content 
scanning of the residual E-mail) it is a big and important step in returning 
control over their inbox back to the recipient... the person who is paying for 
it, and the person who is inconvenienced when their inbox overflows and blocks 
further incoming (often very important) mail.

>If you're trying to help the ISPs--why haven't any of them supported your idea?

Haven't discussed it with them yet (at least not directly, I don't know how many 
of them might be lurking here).

I first proposed my permissions list idea (here, at least) just about a week ago 
(a little bit earlier over on the spf-discuss list) and so to expect people to 
jump (publicly!) on the bandwagon that soon is fairly unrealistic.

Also, even if one or more of them ARE lurking here and maybe are or will be 
setting in motion a plan to implement something like what I propose, (or even 
just to discuss it at their inhouse strategy meetings)... since the result is 
one of those "competitive advantage" type of things, I wouldn't expect expect 
them to trumpet their interest publicly until they're ready to actually announce 
something.

>>(at least relative to without it!) by use of my permissions list... certainly

>You have made no such thing obvious.  In fact numerous people have 
>disagreed with you.  I've asked you for evidence of your belief--you 
>haven't even tried to provide it.

This has been discussed many times, go back and look over the archives for more 
details.

FACT 1:  Either spammers change to plain ASCII text E-mails or they don't.

FACT 2:  If they do, their spams will typically be something like 70% smaller 
(and sometimes A LOT MORE than that, depending on how much 
pure-bulk-HTML-based-obfuscation they added before).

FACT 3:  If they don't, their spams will be blocked by the default "no 
HTML-burdened mail from unknown/untrusted sender" policy.

Further, if they DO change to plain ASCII text E-mails, their mails will become 
easier and faster for content filters to deal with (and flatly preventing them 
from creating some new HTML-based strategem for avoiding the filtering), 
reducing the residual still further.

Their at-least-somewhat reduced (due to no HTML, no scripting, etc) ability to 
deceive in such E-mails also puts another rock in the path of the spammers being 
profitable, which is also likely to discourage at least SOME of them.

So, now, which of those three FACTs do you still pretend you disagree with, and 
why?

>How do you figure that?  Most viruses spread through address books. 
>If someone is in your address book, then you've almost certainly 
>communicated with them, in which case they'll clearly accept HTML 
>mail from you.

Right, but you probably don't accept attachments from the great majority of them 
(and if we implemented the further attachment-TYPE sublevel permissions, you 
probably accept executable attachment types from even fewer still).

And your point anyhow is a bogus one, at least in MY case, since none of the 
people *I* correspond with are likely to have their permission list set to allow 
*me* to send them HTML-burdened E-mail.  I just don't do that.

Likewise, a lot of the (often larger) senders that many people get mail from 
regularly (Yahoogroups lists, newsletters, mailing lists like this one) are not 
HTML-burdened so those senders wouldn't have to be set to allow HTML, either.

So your "you've almost certainly communicated with them, in which case they'll 
clearly accept HTML mail from you" is simply wrong.

>Evade filters.  Yes.  Confuse users?  Yes for some illegal scams. 
>But I seriously doubt that the majority of the spam out there uses 
>that technique.  Please provide numbers.

Sorry, that request goes beyond our "free support level". :-)

>On the contrary.  Payment systems clearly could have an impact on 
>spam.  

Is "could" your evasion, rather than "would"?  Anyhow, provide "proof".  You're 
the one who seems to want "proof".

I claim that the FACTS numbered above are pretty clear and unarguable.  Either 
way, I think it's clear that it would "have an impact" on spammers (either they 
change their policies (due to the impact!) and continue to get some of their 
spam delivered, or they don't and at isn't (i.e. impact!)).  You seem to think 
not, but can't seem to explain why.  I don't know what kind of "proof" you need, 
or why you think that spammers wouldn't be affected after arguing yourself that 
they would change their operations (sounds like that's evidence of 'impact' to 
me).

>Unfortunately their impact on normal email is too costly. 
>Ditto challenge/response.

I agree with you on those two points.  (I probably agree with those that payment 
systems would impact spam too, actually, even without "proof" you seem to call 
for, although I personally think the plan is still braindead and 
counter-productive, and hopefully nobody really plans to implement it.)

>I did.  But you refuse to believe it, or to provide numbers to back 
>up your theory.

I must have missed it.  Which of the numbered FACTs enumerated above do you feel 
is not a valid claim, and why?

>Numbers please.  What percentage of spam relies on those schemes.

Again, that analysis and reporting goes beyond 'free support levels'.  :-)

There are lots of folks out there who are willing to toss out programming jobs 
to see who will do 'em for free.  Even some folks who are interested enough (and 
with someone else paying the bills) sometimes to do the work.  In this case, I'm 
not going to take the bait.  Perhaps someone else here would be interested in 
researching that further.

>Is there any possibility that all the people on the list might be 
>right, and you might be wrong?  Or that even if you *are* right, 
>everyone on the lists realizes that your solution is not feasible, 
>either technically, or from a business standpoint, and therefore not 
>worth consideration?

Possibility?  Sure.  Nearly anything's possible.

I feel that my solution is feasible (CERTAINLY it's feasible technically... I 
haven't heard ANYBODY make any serious and convincing case to the contrary).

From a business standpoint, how well it would turn out would depend on how well 
it was implemented (same as a LOT of software projects).  There's nothing in my 
proposal, though, which PREVENTS it from being implemented well.

>"think" != "show"

Again, tell me which of the three numbered FACTS above are probably incorrect, 
and why.

I've put up a number of assertions, you claim you don't agree and that I haven't 
made my case, but you refuse to tell me which specific (and pretty inarguable I 
think) statements you take issue with.

>All the MTAs (if you want to block at that level) 

Doesn't _require_ a rewrite (certainly!!), and could even be implemented as an 
external module apart from the main MTA code.  Again, those are implementation 
details that can be determined during more detailed design and implementation 
stages.

If the logic were to be ADDED to existing MTA software, it would be a 
MODIFICATION (not a "rewrite", I think).  But there are a number of options 
there, with various tradeoffs associated with each.  A lot would depend on the 
needs and other systems in place at specific ISPs.

>and all the MUAs 
>(so as to avoid sending HTML the first time, at the very least).  

To change the default of Outlook Express (say) to "don't send HTML" is a change 
in the default setting.  To refer to such a (very!) minor code change as a 
"rewrite" is quite laughable.

>And 
>then (as you proposed above) you need ways to import and export 
>permissions lists and move them with you.  This in a market where the 
>leading email program doesn't even give you a way to move your 
>*address book* from one computer to another.

I don't make excuses for poor design of other people's software, but please 
don't saddle me (or the industry in general) with their design sins.

There could be a whole variety of ways to handle such issues, and it's not 
crucial to my concept that we even decide on a specific one.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 23 Jun 2003 12:49:50 -0700

> It's not merely that you need somewhat more than 10 states to detect
> elements (as opposed to tags) in order to know, for example, where
> font and color settings end.  Netscape 7 and Internet Explorer do
> various visible things that depends on parsing that can only be done
> with some backtracking.  A trivial example is that both consider
> <!--this--> to be a comment but <!--not-this-- > contrary to
> http://www.w3.org/TR/html401/intro/sgmltut.html#idx-HTML
> Netscape 7 and Internet Explorer consider <!--stuff<and><nonsense-- >
> as two tags instead of one comment.

That bug was originally introduced by Netscape and IE then copied it to be
compatible.

The reason the bug exists is that the Netscape guys had sat through too many
comp sci lectures on yacc and LR(1) parsing. They never did clue into the
fact that Goldfarb had never read that stuff and that as a result parsing
SGML with an LR(1) parser is a not-happening proposition.

		Phill