(I know I'm going to regret posting this, but the whole argument is just
getting silly.)
> Point-to-point e-mail should be sacred though. What I send you should
> be delivered to you intact. If you choose to demime it or filter out
> naughty words, that's up to you. AOL's millions of users have no
> control over the message munging they're doing--other than by
> switching ISP's, which is a very high price to expect users to pay.
It has never been sacred, though.
What if I send a mail with 'From ' at the beginning of a line? Many
servers and clients escape this in different ways... some put a > before
it... others put a . before it... still others force any message containing
'From' as the beginning of a line as quoted-printable. Does this mean that
each of those clients is creating a unilateral standard and breaking other
things? Oh, gosh, let's go string up the Forte team, they force messages
containing 'From ' at the beginning of a line into quoted-printable! Oh,
no, wait, that's okay, let's go string up Mark Crispin and the PINE
developers for using '>'! No, wait, let's...
My point, mild sarcasm aside, is that whether or not AOL is in the right,
they're /hardly/ the first to munge messages to protect users from parsing
errors/problems. One thing that almost anyone who has written software to
parse or generate e-mail learns quickly is that you have to be willing to
accomodate many varying standards. Problems arise in e-mail parsing and
generation /frequently/. If there's no standard, then you have to find
your own way to solve the problem - hence the dozen or so different methods
of escaping 'From ' in e-mail bodies, for example.
On this topic in particular, there has been a push anyway to have
angle-brackets banned from message subject lines because of the growing
number of web-based e-mail providers. Right or wrong, other e-mail
providers will start doing similar things. I believe Hotmail already eats
all angle-brackets in subject lines, which seems to be equally 'evil' in
this context.
No, it's not 'right' to break BestServ that way. But on the other hand,
I've encountered problems where large providers do something weird that
breaks software I write... I find it better to add support for that service
in some way so that my users on that service don't get slighted. Sure,
I'll talk to the service provider about the problem... but sometimes
they'll come back with a legitimate reason. And in the meantime, I have a
fix in place so that people can get on with life.
The Internet is a lot bigger pond than it used to be, and as a result, the
types of data you can /legitimately/ expect to see are exponentially
increasing. Examples are more and more clients and services send in HTML
format by default; this breaks some older list software that cannot handle
multipart/alternative, or which cannot parse HTML. Or for European
subscribers who send their mail in extended charactersets...
With so many legitimate standards out there, some of them do conflict. And
people do define their own extensions... it is a fact of life. When things
conflict, people will find ways to work around it... and workarounds
sometimes break other standards. It's a fact of life in today's world.
So... my recommendation would be that we put aside the 'is AOL wrong'
argument and try to help Cyndi find a /solution/ to the problem. My
personal recommendation would be to stick a simple little filter in front
of the list approval/subscription address, and if you find <. in the
message subject, eat that period. If it will stop this argument and let
the list get back to something useful, I'll even write the procmail receipe
or the script or whatever is needed to do that for Cyndi so we can all get
back on with life. :)
--Rach
