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(_dot_)paypal(_dot_)com(_at_)%nn%nn%nn(_dot_)%nn%nn%nn%nn%nn(_dot_)%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://www(_dot_)microsoft(_dot_)com(_at_)192(_dot_)168(_dot_)1(_dot_)10/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.
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.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg