> First off, I've made some immediate changes:
>
> 1) the footer at the bottom of every message has been removed
> (its still on the digest and index)
> 2) the listname prefix on the subject of the messages has been
> removed
> 3) I created filters to catch and seamlessly redirect all of
> the old-style commands to the new commands
> The first two items on that list are quite useful features for lists with
> newbies on them. However, on lists with more net-savvy members they are
> often unnecessary. For now I have left the headers unchanged.
The list membership should consider whether the list server
should set a Reply-to:<list address> or not.
The Message-ID tampering must stop. See below.
> Now I'll try to address a number of issues raised by the
> list. If I miss something or you want to discuss any point
> further, I encourage you to write to me privately rather than
> the list. While it does affect everyone, there are hundreds of
> people on the list and none of them signed up for a list server
> debate. If interest warrents, we can even create a separate
> temporary list just for discussing this.
Sorry, but some of these issues affect the health of the community
of subscribers. We will decide when we are tired of this topic.
When we want guidance from you on the selection of topics, we will
ask you.
Besides, you sent the message with a Reply-to:<list> header. <grin>
> 1) Header MessageID rewriting
> Lyris rewrites the MessageID on messages it sends for two
> reasons. First of all, it actually generates a new, unique
> message for each recipient. This has a tradeoff with bandwidth,
> but it enables each message to be customized for the recipient
> (and without changing the messageid's, some Large Proprietary
> Mail Systems would cache the message and not deliver the right
> copies).
This violates a very fundamental principle of email. The
Message-ID and signature go together. If you put a different
Message-ID on a message I signed, you have misappropriated my
intellectual property and created an unauthorized copy. The
members of this list are relatively well versed on this matter
as compared to the average list administrator and you sould
consult us if you need help.
> If the header it is producing violates some RFC, both myself
> and the developer would be very interested in tracking down the
> problem and fixing it. Feel free to contact me directly.
The author of Lyris is a personal acquaintance of Chris Lewis,
and you may wish to coordinate your efforts with him.
> 2) Special substitution tags
>
> You know the line... "This is not a bug, it's a feature!"
> You all have noticed that Lyris has some Perl-like substitution
> tags in it. These are used primarily for server generated
> messages to insert recipient specific information. It allows us
> to put a failsafe List-Unsubscribe header in, which is unique
> to the recipient and works even when the message is forwarded
> through multiple accounts and gateways. This would have to be
> the #1 problem for list members and admins alike... being
> subscribed under some address but not knowing which one.
Chris, are you listening?
The present behavior of the list processor is that it appends
the footer first and substitutes in the message body after.
This logic is leading to erroneous substitutions in the author's
message body [serious no-no].
For example, it would be possible to generate a tailored footer
which the group _might_ accept (I do't want to prejudge) if the
substitution is done _to the footer template_ before it is
appended to the message. The list processor should not be
re-writing the message body, in general. One can often get away
with appended footers.
> Things will work best if you don't use them in your posts. They
> are uncommon enough that they should be easy to avoid. Without
> them attached to the bottom of every message, they should be
> easy to forget about. However, if you feel you must use them,
> they are fully documented at
> <http://www.lyris.com/help/LyrisMailMerge.html>
That's just unacceptable. See the discussion above.
Al
[
Usenet Hypertext FAQ Archive |
Search Mail Archive |
Authors |
Usenet
]
[
1993 |
1994 |
1995 |
1996 |
1997
]
© Copyright The Internet FAQ Consortium, 1997
All rights reserved