ietf-asrg
[Top] [All Lists]

Re: [Asrg] Grouped reply on permissions lists

2003-06-20 13:16:31
From: gep2(_at_)terabites(_dot_)com

... 
(Could you adjust your line length to less than 78?  My ancient MUA
doesn't rewrap lines, and I think it shouldn't.  I control my own line 
lengths by piping paragraphs through `fmt` as I edit them with `vi`.)

Could, but in my experience the artifacts of doing that tends to
be worse rather than better, since one ends up with chewed-up
interlaced paragraphs that are even more frustrating.  Sorry.

What's that about interlaced paragraphs on text with proper lengths?
Typing like an old fashioned typiest and hitting "Return" before the
right margin yields text that is far more intelligible.  It seems
you've switched to no hard line breaks except at the ends of paragraphs.
That's better, or less bad, than your previous 79-83 character lines.
I can send a 300 character paragraph through `fmt`, quickly add '> '
to the beginnings, and produce something that's legible in the archives.
79-83 character lines are a royal pain to quote.


...
Yes, but until ISPs can tell users who complain "run the Netscape or
Microsoft auto-update mechanism", they will not and cannot do such
filtering by default.

I'm not sure I understand your comment.  The reason they would
want to change THEIR mail software would be so it would NOT generate
HTML-burdened E-mail by default.  To truncate the undesirable/untrusted
stuff earlier on the transmission/delivery path (BEFORE wasting as
...

Fine, but no non-trivial ISP that wants to keep its users, and for that
matter, no "IT" department that wants to keep its empire could start
filtering incoming HTML mail by default this month or even this year.
Local users would revolt because a large fraction of their incoming mail
would be bouncing.  Until mail that is legitimate except for gratuitous
HTML encryption is largely gone, no large outfit can filter HTML by default.

The most that any large outfit can offer is to filter HTML mail for
users who ask for such filtering.  There are many ways to do that
today.  I think one is to use a Milter version of SpamAssassin, although
I'm not sure if all of those support per-user control files.  It's
certainly easy to do during delivery with SpamAssassin, Procmail, and
many other mechanisms.


...
So turn off HTML until the the user makes some text bold or purple,
and then silently and automatically switch to HTML.

[Or, pop up one of those dialog boxes alerting them that
HTML-burdened mail adds 3-5x to mail bulk and isn't welcomed by
all recipients, and allowing them the option of proceeding or going
back to plain ASCII text... with maybe an option box they can check
which says "don't warn me about this in the future."]

Fine.


...
IMHO, blocking an email message because it's base64 encoded is 
misguided. Here's a case in point: There are gateways out there that 
will switch encodings on messages.  ...

While I understand your point, I think I have seen EXACTLY ONE
such message that I can recall (and THAT one was spam, where the
encoding was used just to obfuscate the mail content), and I suspect
that the number of remaining 7-bit-only MTAs is exceedingly small.

I've seen plenty of headers on mail saying that base64 encoding has
beem removed.  I've also seen plenty of spews with some samples
encoded and some not.

But regardless, what's your point about Base64?  It does nothing to
help spammers or hurt filters.  The first is why relatively little
spam is current base64 encoded.  Base64 encoding wastes 30% of bandwidth
and disk space, but that's not a reasonable concern given the small
fraction of total traffic that is all email.  HTML as it is commonly
processed by receiving MUAs has many evils, but base64 is merely a
trivial waste of bandwidth.


...
Or were you instead proposing that everyone in the world upgrade
their email client to something that uses "pull" instead of "push"?
Please can we be serious?

I'm being PLENTY serious... you are the one talking about silly stuff.

As far as I've understood them, some contributors to this mailing list
have seriously proposed replacing all SMTP with a pull protocol.
In limited situations, such as newsletters and some (but not all)
equivalents to netnews, that position makes sense.  Otherwise, not.


Vernon Schryver    vjs(_at_)rhyolite(_dot_)com

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