HTML is not, and has never been, a precise or deterministic page layout
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.
Personally, I think that most users are educable. We ought to give them the
information they need to make good choices.
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).
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. :-((
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.
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.
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.
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
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).
...(which probably wouldn't indicate, anyhow, what TYPE of attachments you'd
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.
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.
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.
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.
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?
xxx(_at_)foo(_dot_)com
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.
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.
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.
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.
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.
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
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?
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
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.
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.)
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". :-)
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.
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 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. :-)
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?
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
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.
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
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.
You've shown no benefit,
Rubbish.
I think that the benefit is substantial and UNDENIABLE.
"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.
Which software are you talking about that you think would have to be
"rewritten"?
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.
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