Re: [Mailman-Developers] Reply-To munging considered *carefully*
UGH. I hit Send by accident, going for the menu bar. I hate my mouse. Sorry for the dup.
Note, I am not subscribed to mailman-developers@python.org, so this message may or may not get through to that list. I did CC everyone interested so far, though (I think), in this subthread.
On Tue, 2009-10-13 at 16:03 +0900, Stephen J. Turnbull wrote:
Reply-To set to me. Please verify that your replies are going to the intended place.
Indeed, Ctrl+R does reply to you.
Michael B. Trausch writes:
In any case, it's off-topic, and unless others here are interested in the discussion, or there's a chance that the ML config would be changed, it's probably best just to drop it altogether.
I'm not sure where discussion will take place. Not here, possibly Mailman Developers ML, most likely wiki.list.org. Drop me a line and I'll make sure that you're notified about the new venue. It will probably be Saturday or so.
I assume that since we've already gone there, that's where it'll be. I assume I'll know shortly after I hit C-RET if I need to be subscribed there, too...
As long as I'm here, let me respond.
I've seen that argument before; it's fine, but the ideal situation is impossible to achieve (some form of complete consistency amongst all mailing lists globally).
The draft RFC admits that. It's not a panacea, it's a path forward.
The problem to date, AFAICT from the litter on the path to RFC 2822, is that a lot of people want a way to indicate that responses SHOULD go to the list (of course you can't *force* them to go to the list). They have insisted on coopting Reply-To and Mail-Followup-To for that purpose because they are existing headers that many MUAs already respect. This breaks their usage as defined in the RFCs, so the cooler heads have refused to sanction such usage. They are for the *author* to indicate where personal replies and public discussion, respectively, should be conducted.
The upshot is that there is no RFC-sanctioned way for a list to say "please respond here", and no way at all that doesn't usurp *both* the author's and the receiver's options.
The best way to do this far simpler, I think:
- Mailer software should reply to From or Reply-To as currently.
- ML software should set Reply-To _UNLESS_ there was _already_ a Reply-To. Then, Reply-To isn't truly broken, because the author has control over it still, and it just defaults to the list.
This manages to make things work 95% of the time for 95% of the people. I know that people far less technical than myself expect the behavior above. I don't know about ML's and whether or not they'll respect and author-set Reply-To if one is set in the ML configuration, but I've never tried, either; I do know that of the lists I'm on, the Bazaar ML and one other one (don't remember right now which one) are the only two that actually don't set Reply-To.
Now, RFC 2822 says that From, Sender and Reply-To are "originator fields". It also says this:
When the "Reply-To:" field is present, it indicates the mailbox(es) to which the author of the message suggests that replies be sent.
AFAIC, _this_ author wants replies to his posts to go to a ML unless he says otherwise. That would tie with #2 above, and it seems to me to be a quite reasonable default.
As things currently sit, the default would seem to be "reply to me, unless I say otherwise," which doesn't make sense in the context of an ML. So, this is a bit of a higher-level discussion than the RFCs really provide for. Further, RFC 2822 doesn't prohibit mailing lists from setting Reply-To, and discussion about that would seem to me to be splitting hairs as to where the author suggests posts go in the first place. Your page says that it applies to the originator of the message, but the RFC does not say that; it says that it's an originator header, and from the POV of my Inbox, that's exactly where the mail comes from (e.g., the message comes from human A sending message A, and then the ML server receives message A and becomes the new origin, sending out messages A(1), A(2), ..., A(n)).
IOW, reply-to only makes sense in its default (none, that is, reply to from) in interpersonal communications or self-made "distribution lists" where From == To and the recipients are all Bcc'd.
I would say that if ML software _always_ overrides reply-to, even when the author explicitly provided one, then that is broken. And that does leave the odd corner case of "My outbound origin is user@machine.example.org but I want inbound mail to go to user@example.org" unhandled, but I think that is such a rare case that they would expect misdirected mails in that event.
The intention is to fix that. I already have agreement in principle from the Mailman boss to implement for that list manager. I will provide an implementation of my algorithm that can be used in Emacs MUAs. I'm sure I can get VM and MH-E to adopt it, and almost sure Gnus will. The KDE KMail guy has expressed interest. Both seemed to think my proposal is actually novel, but I certainly will check the IETF archives in order to frame it properly in existing discussion.
On the topic of the discussion, though, what is better for all is a default behavior that is correct, say, 95% of the time for 95% of the people.
My algorithm gives that by default. The draft RFC gives a way for a mailing list to either insist on public followup or to strongly discourage it.
In the event of:
- user reports problem to ML
- admin asks for info (s)he knows to be sensitive
- user replies to ML
This is easily fixed by the admin explicitly setting reply-to for that single message. However, reply-to becomes meaningless in such a situation where admin x always sets the header (as in the odd case I mentioned above), again because of the misdirected-reply problem.
So, in the end, I think that the algorithm you mentioned is a good step in the right direction, sure. But I think the ultimate solution is even simpler than that: Use the reply-to standard header to make it possible for users to "do what they mean", by setting a default and using it when a message comes in that _doesn't_ have a reply-to set on its header and is intended to be posted to the list.
Even better, this eliminates the problem of:
I post message A without reply-to:
To: ml@example.org From: mbt@zest.trausch.us
Someone responds with message B and hits reply-all, also without reply-to:
To: mbt@zest.trausch.us Cc: ml@example.org From: user@example.org
And then I don't get a message with a List-Post header _at all_. That is one failing that your algorithm cannot fix, unless the ML sends its second copy (and most MLs are configured not to do so, because users find it inconvenient).
--- Mike-- Blog: http://mike.trausch.us/blog/ Misc. Software: http://mike.trausch.us/software/
“The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.” —Michelangelo
Michael B. Trausch writes:
[This was me, stephen, but the attribution was dropped:]
The upshot is that there is no RFC-sanctioned way for a list to say "please respond here", and no way at all that doesn't usurp *both* the author's and the receiver's options.
The best way to do this far simpler, I think:
- Mailer software should reply to From or Reply-To as currently.
- ML software should set Reply-To _UNLESS_ there was _already_ a Reply-To. Then, Reply-To isn't truly broken, because the author has control over it still, and it just defaults to the list.
Reply-To still is truly broken. The author wants personal replies to go to her, but now they go to the list. The recipient must *specifically avoid reply-to-author* in order to reply to the author. This is so Orwellian.
IOW, reply-to only makes sense in its default (none, that is, reply to from) in interpersonal communications or self-made "distribution lists" where From == To and the recipients are all Bcc'd.
Stop deprecating use cases that you don't use. They exist, are important to their users, and what you are advocating is tyranny of the majority. Not on our Internet, please.
I have no objection to the functionality you want, but I take *strong* exception to having the very useful Reply-To field *hijacked* so that you don't need to wait for my proposal to be implemented.[1]
So, in the end, I think that the algorithm you mentioned is a good step in the right direction, sure. But I think the ultimate solution is even simpler than that:
Except that it is *not* an ultimate solution, because the function of the Reply-To field is lost in important cases. A new Reply-To field that third parties are prohibited from munging would have to be defined. Why do that when we already have one?
Footnotes: [1] The problem of the wrong dupe being eliminated is *not* a problem with Reply-To, although it may be made more frequent. It's simply the case that if access to the List-Post field in every message is desired, the mailing *cannot* do dupe elimination. *Not* *at* *all*. Your use case here is broken. Badly.
On Wed, 2009-10-14 at 12:55 +0900, Stephen J. Turnbull wrote:
Michael B. Trausch writes:
[This was me, stephen, but the attribution was dropped:]
The attribution was _not_ dropped, it was at the top of the message in standard inline-reply fashion. You may want to double check the message to verify that:
http://www.mail-archive.com/mailman-developers% 40python.org/msg11590.html
Short link to the same resource, in case of breakage: http://is.gd/4iD4o
The upshot is that there is no RFC-sanctioned way for a list to say "please respond here", and no way at all that doesn't usurp *both* the author's and the receiver's options.
The best way to do this far simpler, I think:
- Mailer software should reply to From or Reply-To as currently.
- ML software should set Reply-To _UNLESS_ there was _already_ a Reply-To. Then, Reply-To isn't truly broken, because the author has control over it still, and it just defaults to the list.
Reply-To still is truly broken. The author wants personal replies to go to her, but now they go to the list. The recipient must *specifically avoid reply-to-author* in order to reply to the author. This is so Orwellian.
Permit me to rephrase so that you understand what I said:
There are two major uses of email, discounting automatically generated messages, corporate crap and spam: email from one person or to one person or a group of people, and email from one person to a mailing list (presumably with people on it). Whether the emails are in a personal, hobbyist, collegiate, educational, or professional context, the patterns are largely the same. In both events, 95+% of the time, there is no reply-to header attached by the authors MUA.
However, the primary use-case for a mailing list is _group_ _discussion_. Or at least, so I thought. Call me silly, but if it's not meant to be group discussion as the primary role, maybe mailing lists should stop using server software and become ad-hoc, old boys' club style, personally shared and replicated distribution lists, nothing more. Being that is the case, and that is what users of mailing lists _expect_, it is reasonable to assume that the way reply-to is handled would be thus:
I send an email to the mailing list to start a thread of discussion. I send no reply-to header on the message, so the list processing software appends one redirecting replies to the group. This facilitates group discussion. It's not Orwellian, it's common sense---if, of course, we make the assumption that mailing lists are for, you know, group discussion and not private communication. If I want to communicate privately with someone, I won't be sending the mail to a mailing list; if I need to communicate with someone who is on a ML privately, and I don't have their address, that's what ML archives are for (or, sending a mail to the ML to ping them, or searching my own archives, if the public archives have that information stripped).
During the course of the thread, it becomes clear that some sensitive information must be sent (to address your use case from your Web page from earlier in this thread). That's totally not a problem: The person asking for the sensitive information simply adds a reply-to header to their outbound message. The mailing list _sees_ this reply-to header, and then refuses to replace it, transform it, or supercede it, because the rule SHOULD be "Only add a reply-to to a message if it does not have one already." I don't know if there is _any_ software that does this currently out there, but if there isn't, that's something that is at least easily fixed in any system even if it's horribly designed. It translates to nothing more than a single if statement in code. It'd be trivial for users of non-proprietary systems to adopt even if they don't want to upgrade their mailing list software.
Now, there is of course an alternative mechanism that could be used to meet the same need: Have a header, say, X-List-Please-Reply-To-List, that a MUA could add in a generic fashion to all mail messages. That could signal to the list processing software, "Yes, Please, I WANT people replying to my messages to reply to the list." However, I don't see that as at all likely to occur.
For me to fit into your suggested solution, I'd have to wait for both your algorithm to be ubiquitous in MUA software _and_ all mailing list software to be upgraded or replaced to make the headers it depends on to be ubiquitous.
Still, to get truly sane behavior, I'd have to use Alpine. Why? The MUA _can_ do what I meant, and it can do it _easily_. There is _nothing_ that will fix the situation of no-duplicate-posts and the associated "Oops, I sent that to you and I meant to send it to the list as well," unless the MUA does one of the following (either by default, or by configuration):
- Uses "reply to all" as the default behavior (config item), or
- Asks you what you want to do when there are multiple recipients to the message that you're replying to (could be a sane default _and_ a config item)
Alpine does the latter by default. I have used no MUA that does the former (that I am aware of; some of them perhaps did, but I've tried many and quickly fled any that are buggy in areas that I cannot fix and impact my usage patterns), and I don't know of any other ones that behave the way Alpine does. If Alpine fit better into my workflow overall, I'd use _that_ instead, solely for that single feature. Why? Because while it may not be smart enough to do what I meant for it to do, it is smart enough to recognize that fact and _ask_ what I mean for it to do.
Unfortunately, most MUA software seems to take as an axiom that humans are infallible and will always do The Right Thing. Call me silly, but I have software to help me to do that in many ways; if I didn't want that, I'd type my messages directly into a socket, speak SMTP myself, and likely do so using an 8088 with DOS running a tiny network stack and with frequent calls to INT 0x21 and INT 0x60. Thankfully, that's not required, nor do I desire it.
IOW, reply-to only makes sense in its default (none, that is, reply to from) in interpersonal communications or self-made "distribution lists" where From == To and the recipients are all Bcc'd.
Stop deprecating use cases that you don't use. They exist, are important to their users, and what you are advocating is tyranny of the majority. Not on our Internet, please.
I didn't deprecate _anything_. I'm going to give you the benefit of the doubt and assume that you must have had a really bad day or something.*
I have no objection to the functionality you want, but I take *strong* exception to having the very useful Reply-To field *hijacked* so that you don't need to wait for my proposal to be implemented.[1]
So, in the end, I think that the algorithm you mentioned is a good step in the right direction, sure. But I think the ultimate solution is even simpler than that:
Except that it is *not* an ultimate solution, because the function of the Reply-To field is lost in important cases. A new Reply-To field that third parties are prohibited from munging would have to be defined. Why do that when we already have one?
Citation, please? I already quoted the part of RFC 2822 that shows that semantically speaking your assertion is incorrect. If there is an RFC that supersedes the definitions of RFC 2822, I'd like to see it. At present, I am not aware of one. (Further, if there is additional clarification that I've missed in my readings of RFC 2822, I'd like a pointer to that, as well; I've already read it once today, maybe I'll review it again later for things I missed in today's reading.)
In my (admittedly, limited in terms of global and topical coverage) personal experience, _most_ mailing lists are poorly configured on the extreme of users not being able to specify a reply-to at all, because the reply-to is stripped and subsequently replaced by the mailing list software. Clearly, this is _bad_. Is it wrong? Not according to RFC 2822, because the mailing list processor is the logical origin of a message and thus it is clear to send the header---or not---as it sees fit. However, what sparked this thread was a practical concern regarding a very common usage pattern, not a concern that everything be 100% idealistic and precisely fit some standard as interpreted by random person X.
In other words, what we're talking about is left---according to the ambiguous text in RFC 2822---as an implementation detail of mailing list processing software.
Footnotes: [1] The problem of the wrong dupe being eliminated is *not* a problem with Reply-To, although it may be made more frequent. It's simply the case that if access to the List-Post field in every message is desired, the mailing *cannot* do dupe elimination. *Not* *at* *all*. Your use case here is broken. Badly.
I never *said* it was a problem with reply-to. I _did_ say that by adopting a sane default (but able to be overrode by the sender _simply_ by using the header him/herself) value is a practical thing to do, is useful, and fits 95% of the people's workflows, 95% of the time---maybe more, maybe less, but I don't believe I'm terribly far outside of the ballpark. In _ANY_ system there is going to be exceptions, but guess what? That's because we are human, and no matter how pedantic or technical we are, we're going to screw up occasionally.
If this conversation is going to degrade into slinging and retaliation based on emotion-provoking arguments instead of grounded ones, I think it's best that it stops here. If you want to talk about 1984, there's a place and time for that; if you want to overlook details, I'm sure there's one for that, too. I was talking about a practical matter, and it was just a comment (regarding my MUA, which I am _well_ aware could behave better, and I simply do _not_ have the time to make that happen right now). It wasn't supposed to blow up into a huge argument of religion and who can interpret RFCs more conservatively or liberally than the other.
Have a better day tomorrow,*
Mike- My wife seems to think that I come off sarcastic in those statements. In case that is how you read it, allow me to assure you, that is not my intent.
-- Blog: http://mike.trausch.us/blog/ Misc. Software: http://mike.trausch.us/software/
“The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.” —Michelangelo
On 14-Oct-2009, Michael B. Trausch wrote:
On Wed, 2009-10-14 at 12:55 +0900, Stephen J. Turnbull wrote:
Reply-To still is truly broken. The author wants personal replies to go to her, but now they go to the list. The recipient must *specifically avoid reply-to-author* in order to reply to the author. This is so Orwellian.
Permit me to rephrase so that you understand what I said:
There are two major uses of email [for actual discussion]: email from one person or to one person or a group of people, and email from one person to a mailing list (presumably with people on it).
I can't parse the above into two; I assume there's a mistake, and that you meant “email from one person to one or more people, and email from one person to a mailing list”. If you meant something else, I'm not seeing it.
However, the primary use-case for a mailing list is _group_ _discussion_.
Yes. This majority use, though, should not make it more difficult to use “reply to author”.
As has no doubt already been pointed out in this discussion, the failure modes are wildly unbalanced:
“Whoops, I sent a message intended for the whole list instead as a reply to the author. Oh well, I'll re-send the reply to the list.” Annoying for the two people involved, but no permanent harm done.
“Whoops, I sent a message intended only for the author instead as a reply to the whole list.” Completely the opposite of what “reply to author” is supposed to do, and unrecoverable.
- I send an email to the mailing list to start a thread of discussion. I send no reply-to header on the message, so the list processing software appends one redirecting replies to the group.
It directs the “reply to author” replies to the group, despite the intent of the respondent. A recipe for disaster, as has been demonstrated countless times over the years.
This facilitates group discussion. It's not Orwellian, it's common sense
The Orwellian behaviour is that “reply to author” has been perverted to mean something *totally* different.
For “facilitate group discussion”, we have the “reply to list” operation — implemented in most modern mainstream MUAs, and plenty of pressure on the few recalcitrant vendors to get it right.
- During the course of the thread, it becomes clear that some sensitive information must be sent (to address your use case from your Web page from earlier in this thread). That's totally not a problem: The person asking for the sensitive information simply adds a reply-to header to their outbound message.
This picture is so contrived I can't think of any situation where it's actually played out as you portray it. Rather, the *person who wants to send the private information* is the first one to know that's what is needed — so they hit “reply to author” to send a reply to the author of the message they're looking at.
Under your proposal, their intent is betrayed — deliberately, by the mailing list software. Even though the mailing list software is *also* making available the standard RFC 2369 information facilitating group discussion.
-- \ “The greatest tragedy in mankind's entire history may be the | `\ hijacking of morality by religion.” —Arthur C. Clarke, 1991 | _o__) | Ben Finney ben@benfinney.id.au
On Wed, 2009-10-14 at 17:30 +1100, Ben Finney wrote:
On 14-Oct-2009, Michael B. Trausch wrote:
On Wed, 2009-10-14 at 12:55 +0900, Stephen J. Turnbull wrote:
Reply-To still is truly broken. The author wants personal replies to go to her, but now they go to the list. The recipient must *specifically avoid reply-to-author* in order to reply to the author. This is so Orwellian.
Permit me to rephrase so that you understand what I said:
There are two major uses of email [for actual discussion]: email from one person or to one person or a group of people, and email from one person to a mailing list (presumably with people on it).
I can't parse the above into two; I assume there's a mistake, and that you meant “email from one person to one or more people, and email from one person to a mailing list”. If you meant something else, I'm not seeing it.
No, that's exactly what I meant; I'm not sure where the mis-read is happening, because what you said and what I said are exactly the same.
However, the primary use-case for a mailing list is _group_ _discussion_.
Yes. This majority use, though, should not make it more difficult to use “reply to author”.
I think that there are some differences in base assumptions here. The initial comment that started this whole regrettable mess was that my software needs to do what I mean. I'm utterly _sick_ of the inconsistency and it's becoming a real drag on getting things done, because of late I have to wonder if I really sent the blasted messages correctly.
We have:
- MLs that allow a MUA to click reply and _just_ reply to the ML, and
- MLs that require "reply all" instead, and instead of sending _one_ message in threading context, send N number of messages where N is however many people are listed in various headers.
Now, _this_ is where the situation is _bad_. It's _awful_. If every single ML worked in precisely the same way, there would be _zero_ issues. Yes, some failure modes would exist that wouldn't in the other one and whatever, but at the very least, the modes of operation would be _consistent_. In such a world, the idea of "do what I mean" is something that we can then teach our systems to do for us. Presently, it is not.
Now, we have in the first category, the "click reply to reply to the message" lists. These lists save bandwidth and make things easy for the _vast_ majority of use cases by not requiring the user to track nearly anything. They're automatic, and they Just Work. There is, of course, the potential downside of someone sending information to the list that they did not intend to do so. That is certainly a valid risk. Is it annoying? Yes. Could it potentially be disastrous? Yes, though most often not because with these types of lists most risk is easily mitigated because it's caught early enough to have something done about it through one of many channels.
On the other hand, we have lists that don't do that. And for those, we must have MUAs send multiple messages; at minimum, two: one to the author of the message being replied to, and one as a Cc: to the mailing list. This introduces failure modes that are _consistently_ annoying and not easily automatically dealt with, ranging from issues like broken mail filters (because some lists don't have a [list] appendage in the subject and thus one must filter on a List-* header, which is not present when you are in To: or Cc: _and_ the message is sent to the ML), to not posting to the list at all. And I'm far from the only one that has encountered these frustrations recently on various MLs.
How can these be handled?
Again, let's look at the first type of list. There is a possible automatic solution, and (more likely to be used on lists where it could be a persistent issue) a less automatic means employing convention. The automatic solution would be MUA-side, not ML-server side, in that MUA software would prompt the user ("How do you wish to reply? [To List] [To Sender] [To All]"). The user could choose one to be the default if desired, and then the burden of responsibility is (rightly) on them. This is similar to what Alpine implements, though better. There are a couple of other automatic solutions, as well, which I will only mention in brief, because I don't think anyone really cares about them:
A List-Hold-For MUA header with a sane maximum value (maybe 1800 seconds). ML could send a reply that users could act on (meant to, didn't mean to) and if it times out based on the header, the ML would go ahead and post the message. A Web UI could also work.
A List-No-Archive MUA header, which clients could set by default if desired which would confine leakages to recipients and not archives or mail/nntp gateways, though the downsides of that would be obvious.
A List-User-Confirmed MUA header that could be set by user agents in combination with a prompt from above, and the ML server could send an autoreply to a message with L-U-C not set and ask "Did you mean to do that," with a timeout of 1 day or so and a default action of not posting the message if no action is taken before its timeout.
A List-Never MUA header that would cause ML software to reject posts, combined with an autoreply to confirm that they really wanted to do that, like ML software could do in the absence of a L-U-C header. MUA software could set/not set this option by configuration items.
Any of the sorts of ideas above that generate an autoreply would be useful with state: The ML server could add a List-AutoReply header that the MUA could use to present a better UI to the user instead of displaying the message, with List-AutoReply-Approve and List-AutoReply-Deny headers specifying a URL that can be handled by the MUA software (or passed to an external program, say a Web browser) when the user wants to approve or deny a post. Autoreplies would also have the original message as-would-be-posted attached.
There are, of course, other variations on any of those ideas that could be put into practical use. The best solutions would depend on zero MUA features, while providing more featureful MUA software with the ability to better handle many of the situations. Autoreplies in a knowledgeable MUA could be hidden entirely and just presented to the user as UI dialogs or windows or similar.
Another solution would be to have a dedicated address for certain types of sensitive email. Say, an email address for a team or private, non-archived mailing list that accepts posts from non-subscribers and is handled by people who are responsible and won't leak things. Then, when someone says, "Please send the details to private-email@example.org", it's clear what is being asked and where it is to be sent. After all, we _can_ assume that humans are, while imperfect, capable of being responsible for their actions and reading the messages that are sent to them. If we cannot make that assumption, then there really isn't much point to a messaging system of any sort, much less a widescale one like email, is there?
In the second type of list, sure you have private replies by default, but you then make _everyone_ on the list have to reply-all or whatever. Additionally, you make _everyone_ on the list try to find ways to filter their list posts and replies into a folder, and many MUAs are not featureful enough to try to compare incoming messages with a references or in-reply-to header to previous messages for the mailing list, and even so, it'd be error prone (what if the referenced messages are deleted?) and kludgey. Are such lists useful? Of course, but they are much more work for everyone involved when compared to the simplicity of the other type of list. Because it is certain that not 100% of the mail will pass through the mail server, no automatic features can be used to help the user out either on the ML server side or on the MUA client side, because the MUA does not have enough information to properly do what the user wants it to do at least some of the time.
As has no doubt already been pointed out in this discussion, the failure modes are wildly unbalanced:
“Whoops, I sent a message intended for the whole list instead as a reply to the author. Oh well, I'll re-send the reply to the list.” Annoying for the two people involved, but no permanent harm done.
“Whoops, I sent a message intended only for the author instead as a reply to the whole list.” Completely the opposite of what “reply to author” is supposed to do, and unrecoverable.
What MUA are you using that has a "Reply to Author" option? Most that I know have "Reply" (undecorated) or "Reply to Sender" which could be read one of two ways. While "Reply to Author" is always 100% unambiguous, I don't know that many MUAs advertise their reply that way. Evolution, for example, presents the man UI as simply "Reply" in the context of a message; in the menu it shows "Reply to Sender". Poll 100 end-user types (non-technical people) and you'll likely find 3 answers to the question "What does reply to sender mean in the context of a mailing list post?", with no way to deterministically predict what the percentages are on that.*
- I send an email to the mailing list to start a thread of discussion. I send no reply-to header on the message, so the list processing software appends one redirecting replies to the group.
It directs the “reply to author” replies to the group, despite the intent of the respondent. A recipe for disaster, as has been demonstrated countless times over the years.
Though, as I mentioned above, there are automatic ways to handle those situations that can fend off such things, unlike in the other situation where such behavior is impossible because of lack of data at least some of the time. Some of the means can still be applied to the second type of list, but they don't make sense there because that just adds crap to jump through.
The ultimate point here is that it should be _in the user's control_, not the ML admin's control. Certainly, the ML admin might want to say "No, I won't remove your accidentally posted sensitive information," and the ML admin has no liability to do so. But with any of the safeguards above in place, a ML admin could say that with confidence that the ML users have to deliberately act to post in the first place. Say the timeout method, List-Hold-For, would likely be most useful with a short value (say, 180 seconds by default), because most users realize that they screwed up _immediately_ after pressing the Send button. And guess what? That functionality then lets them cancel their post---putting control of a user's owned words/data in the hands of the user, and lightening the load of the ML administrator. Again, for lists that replies never go through automatically, that's simply not possible.
So if we're going to talk about mitigating leakage issues here? The first type of list with the appropriate safeguards in place that the user can control with simple MUA-side headers and potentially additional UI enhancements on the MUA itself is the _clear_ winner. Somehow, though, I think that this conversation isn't about such things; I think it's about less concrete things altogether.
This facilitates group discussion. It's not Orwellian, it's common sense
The Orwellian behaviour is that “reply to author” has been perverted to mean something *totally* different.
I don't get the impression that we're talking about users here, at all. I get the impression that we're going "Look! See? Bad! We know this to be true! What on earth are you thinking‽", instead. I'm speaking in practical terms, from someone who uses software (and indeed, writes software, administers software, etc., so I'm not a non-technical end user). Using words like "perverted" makes it sound like, "I'm right, you're wrong, now go away."
The standard is ambiguous. I'm sorry if you don't like that, but that _is_ the way it is. On top of the ambiguity there, I think that there is an assumption that whatever user interface that you're using that says "Reply to Author" is some sort of common thing among all MUA UIs, and it's not (probably _because_ the standards are ambiguous, though it could also be because the wording chosen most popularly is slightly more abstract anyway, even if the authors of the MUA don't see that Reply-To can apply to a mail from a ML server just as much as it can from a human directly).
Again, I'm _not_ saying that ML software should override the reply-to header if it's already present in the message (though they do tend to do that anyway, and there's nothing we're going to change here on that). Fact is, they _do_, and that can be turned into something that can be used to prevent the very sorts of user mistakes being talked about here. Why it hasn't been before is beyond me.
For “facilitate group discussion”, we have the “reply to list” operation — implemented in most modern mainstream MUAs, and plenty of pressure on the few recalcitrant vendors to get it right.
- During the course of the thread, it becomes clear that some sensitive information must be sent (to address your use case from your Web page from earlier in this thread). That's totally not a problem: The person asking for the sensitive information simply adds a reply-to header to their outbound message.
This picture is so contrived I can't think of any situation where it's actually played out as you portray it. Rather, the *person who wants to send the private information* is the first one to know that's what is needed — so they hit “reply to author” to send a reply to the author of the message they're looking at.
I forced nothing. The picture was posited earlier in the thread. I suggested a means of dealing with it, that's all. Read further into it if you want, but I don't warrant anything you read beyond the text...
Under your proposal, their intent is betrayed — deliberately, by the mailing list software. Even though the mailing list software is *also* making available the standard RFC 2369 information facilitating group discussion.
You are forgetting that RFC 2369 can _only_ apply if the mail goes through the ML server in the _first_ place.
Forgive me, y'all, for thinking I could talk from a user's point of view. I suppose I should know better.
--- Mike- The answers being, "I don't know," "It means reply to the mailing list," and "It means reply to the person who sent it to the mailing list," or variants thereof. Because people are generally special, you may get more than 3 answers that are "creative".
-- Blog: http://mike.trausch.us/blog/ Misc. Software: http://mike.trausch.us/software/
The FSF merely is returning freedom to software, it did not invent it. But, what of history? Someday the FSF will go, a new proprietary era will come, and someone else will invent freedom in software for the third time.
On Oct 14, 2009, at 4:19 AM, Michael B. Trausch wrote:
- MLs that require "reply all" instead, and instead of sending _one_ message in threading context, send N number of messages where N is however many people are listed in various headers.
This is not a bug in mailing list software, it's a bug in the MUAs.
Despite, as Stephen says, *decades* of complaints such as this, very
few MUAs support the mailing list RFCs that have exists for at least a
dozen years. Fix the MUAs first please.
It's actually easy too. An MUA need only recognize List-Post and add
a Reply to List button which would strip all the recipients and put
the List-Post value in the To header. Problem solved.
-Barry
On Wed, 2009-10-14 at 08:41 -0400, Barry Warsaw wrote:
On Oct 14, 2009, at 4:19 AM, Michael B. Trausch wrote:
- MLs that require "reply all" instead, and instead of sending _one_ message in threading context, send N number of messages where N is however many people are listed in various headers.
This is not a bug in mailing list software, it's a bug in the MUAs.
Despite, as Stephen says, *decades* of complaints such as this, very
few MUAs support the mailing list RFCs that have exists for at least a
dozen years. Fix the MUAs first please.
As I mentioned in the post you replied to, this is impossible because the List-* headers won't be received at all in many normal operating circumstances.
It's actually easy too. An MUA need only recognize List-Post and add
a Reply to List button which would strip all the recipients and put
the List-Post value in the To header. Problem solved.
And therein lies the rub. There are several ways to make the system work more deterministically overall (the list style that seems to be on the side opposite me here is _rarely_ deterministic, though it often kind of works). There are means by which accidental leakage can be avoided on lists that use the Reply-To header as I have already suggested, while not breaking what a non-technical end-user perceives to be expected behavior.
I'm talking about user experience as it pertains to mailing lists and everything that there is to them. I cannot consistently reply without making something incorrect, nor can I consistently filter mailing list posts, because when posts arrive without a header to filter on (as is the case when I recieve someone's reply directly, and not from the mailing list) the filter breaks. Such breakage should be the exception, not the rule. Furthermore, such breakage cannot be fixed in a system where there isn't a single component to be fixed. Suggesting that this can be done MUA-side fails to address several issues that I raised in the post that you replied to that are programmatically impossible to solve consistently.
I was unaware of RFC 5322's clarifications. That does change what I understand to be current standard a bit, but it does not change what I think is proper behavior in terms of how users interact with mailing lists. While both approaches can have inconsistencies about them, there are less of them in a system that uses reply-to with a sane default and does things like I discussed in the parent of your reply, and if any of the mechanisms were adopted that would virtually kill the "Oh, I posted stuff I shouldn't have" problem. I can think of many situations where it'd also be beneficial---say, in a flamefest, where someone sends off a message that they wished they could take back (impossible normally), or accidentally press Send by accident before finishing message composition (such as I did earlier in this thread), or in those few minutes just after someone hits Send and goes "Oh, I _really_ oughtn't to have done that."
It is technically possible to solve these problems. What I don't understand is why there seems to be a large active disinterest in doing so. The mechanisms I mentioned earlier would all solve those problems for all but a very small subset of users---it'd fix the mailing list "user interface" for more users than the current methods do.
Again, I think that _what is_ is being ignored for what is perceived to be _what ought to be_. I'm more interested in the practical concerns at play. Though, it seems that doesn't matter. That said, if mailing list software _did_ choose to modify/remove/replace/append to the reply-to header (mere creation of the header is _not_ munging) it's entirely possible that the ML software could be configured to handle such things gracefully. If the mailing list posts always go through the ML server, it _is_ possible to fix nearly every imaginable use-case, but for that to work, there would have to be some level of interest. IMHO, it's more important to Just Work regardless of what sort of MUA the user has than it is to be pedantic and play the blame game.
If there is a technical solution that can be reliably implemented in an MUA-independent fashion that doesn't depend on any of the things I mentioned in this post's grandparent, I'd be interested in going after it. However, programmatically speaking, I don't see it being possible without saying, "MUAs, these are the standards that you must adhere to," in a separate standards document, describing exactly what sort of behavior is expected to make things transparent and just work, and also sending duplicate messages such that MUA software can recognize the duplicate and show them as a single message. I think that trying to fix it in the currently apparently accepted architecture, though, is terribly much more complex than it needs to be.
What I am proposing is that depending on the MUA to be anything more than a program to send and receive messages is fundamentally flawed, and it doesn't fit in with the UNIX philosophy of program design. The job of managing the mailing list should be on the mailing list management software, no part of it should depend on the MUA. The MUA _should_ be able to provide help in doing so, but everything that the MUA is capable of doing automagically for its users should also be able to be done without depending on the MUA for extra help, in such a way that even very ancient MUA software that still exists out there (albeit in very rare usage) can provide the functionality, using nothing but messages to manage the flow of things.
Maybe what I need to do to really show what I'm talking about is to create an implementation that does what I am talking about so that it can be looked at and discussed?
--- Mike-- Blog: http://mike.trausch.us/blog/ Misc. Software: http://mike.trausch.us/software/
“The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.” —Michelangelo
Since this thread has devolved into the same unwinnable emacs-vs-vim
argument about Reply-To munging, I'm going to disengage.
Mailman's official policy won't change. It considers Reply-To munging
to be a bad thing in the general case, and will discourage its use.
It will still supply the tools to allow list owners to do it, but it
may make such options more obscure. Support for Reply-To munging will
not be removed if only so we can tell list owners to stfu, or to
provide them cover to tell their users to stfu. :)
Mailman also recognizes that there are a few limited legitimate use
cases for a mailing list to indicate where follow up postings should
go, and that there is currently no other way to support these use
cases than Reply-To munging.
Any attempt to impose additional semantics or responsibilities on
Reply-To will only make matters worse. I support Stephen's efforts to
rally consensus and eventual standards around an unambiguous less-
contentious <wink> list-domain header for these use cases.
-Barry
Barry Warsaw writes:
It's actually easy too. An MUA need only recognize List-Post and add
a Reply to List button which would strip all the recipients and put
the List-Post value in the To header. Problem solved.
Wrong problem. The users Michael is representing want a one-button MUA.
Now, nobody has come close to the one-button MUA yet (vc.el is pretty close, but unfortunately it's not an MUA), but the fact is that a *very* large proportion (not to be identified with the value "95%+", lest we rock Mark's coffin) of users get along perfectly well with only one reply button *as long as all their lists munge Reply-To*. See also Russ Nelson' pithy blog: http://russnelson.com/rt.html.
My first response to that fact is "fuck 'em if they can't take a joke, 'cause the joke is their MUA".[1] However, as my mother always told me, you catch more bears with honey than with axle grease (or something like that), and thus the draft RFC.
Footnotes: [1]
On Thu, 2009-10-15 at 02:05 +0900, Stephen J. Turnbull wrote:
Barry Warsaw writes:
It's actually easy too. An MUA need only recognize List-Post and add
a Reply to List button which would strip all the recipients and put
the List-Post value in the To header. Problem solved.Wrong problem. The users Michael is representing want a one-button MUA.
Not at all. I am _not_ only advocating a single position here. I'm advocating that there is, can be, should be, and must be a universally applicable solution found here. That said, I think the MUA is simply the wrong place for it; current models aim to control the user in one way or another, or lack flexibility in exchange for convenience or vice versa. It doesn't have to be that way; it's not 1970, folks.
Perhaps what is really required to make _everyone_ happy is a system that is _designed_ to make everyone happy. Let's face it: Most software in the realm of mailing lists is aimed for at least a marginally technical audience. Why not aim more broadly and create something that _can_ make everyone happy, without saying "your MUA is broken," and for that matter is 100% functional in a manner that is 100% MUA-agnostic.
Only a user can judge if his/her MUA is broken; you cannot do it for me, and I cannot do it for you. If you want to use "mail" at the command line, I'd say that's a poor choice of MUA, but you know what? I'm not you, and so why should I care? It is not my place to impose upon you requirements for proper MUA, Newsreader, Web browser, or any other technology's behavior.
Here is an idea that is a _starting point_, that maybe would be useful to pursue. I doubt anyone here would be interested, but I plan to pursue it anyway:
http://mike.trausch.us/blog/2009/10/14/on-mailing-list-management-software-p... Short link: http://is.gd/4jzy9
--- Mike-- Blog: http://mike.trausch.us/blog/ Misc. Software: http://mike.trausch.us/software/
“The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.” —Michelangelo
Michael B. Trausch writes:
That said, I think the MUA is simply the wrong place for it; current models aim to control the user in one way or another, or lack flexibility in exchange for convenience or vice versa. It doesn't have to be that way; it's not 1970, folks.
How you can get from the last three lines to the first one is beyond me.
My apologies to the rest of the audience for persisting this far. Exit Steve, stage left.
Michael B. Trausch writes:
Now, _this_ is where the situation is _bad_. It's _awful_. If every single ML worked in precisely the same way, there would be _zero_ issues.
Well, yes. That's why there are RFCs, so that software and its users can interoperate over the Internet. You either really don't understand the relevant RFCs (the hypothesis I now favor) or you are advocating nonconformance. Both inadvertant and deliberate nonconformance are bad for the Internet, even if short-circuiting the RFC process seems like it would be real convenient to you and hundreds of millions of others right now.
Forgive me, y'all, for thinking I could talk from a user's point of view. I suppose I should know better.
We're *all* talking from the user's point of view. We all eat our own dogfood here, you know. The reason your proposals are getting treated so roughly is that they involve using *other* people's resources to serve *your* purpose, and non-conformance to an Internet standard that has been 40 years in the making. But the problem that you want to fix is that despite having all the information needed to DTRT, *your* MUA doesn't DWYM!
The solution to that is obvious: fix your MUA, either by fixing it or by switching to a better one. Until you explain to us why that obvious solution is infeasible, you're going to get very little sympathy when you ask us (ie, wearing our list manager hats) to conform to a non-standard that you propose, in violation of an ancient and beloved real standard.
Michael B. Trausch writes:
Permit me to rephrase so that you understand what I said:
I understand what you said. You are not responding to what I said, except emotionally. Stripped of emotional language, the fact is that there are use cases for Reply-To which Reply-To munging overrides. The fact is that the RFCs have consistently, despite *decades* of argument along the lines you proposed, reserved use of the Reply-To field to the originator, who is clearly the author(s) or agent of same. (Otherwise Message-ID-munging would be similarly appropriate.) The fact is that your proposal takes the right to use the Reply-To field *or have the From field used /automatically/ as the destination for personal replies* in all circumstances, a right clearly delegated to the originator by the RFCs, away in *some* circumstances, for the convenience of third parties.
Please respond to those facts rather than assuming I don't understand what you're talking about.
Sorry, I didn't have time in my reply earlier to look up the citation in RFC 5322 (and (nearly?) identical language in RFC 2822). Here it is, along with an apology.
Michael B. Trausch writes:
On Wed, 2009-10-14 at 12:55 +0900, Stephen J. Turnbull wrote:
Michael B. Trausch writes:
[This was me, stephen, but the attribution was dropped:]
The attribution was _not_ dropped,
Sorry, I must have missed it. I assure you I went looking for it in the yanked text. Apparently I had already cut it, somehow. My bad, explanation is not an excuse, only to help assure you it was not an intentional attack.
Except that it is *not* an ultimate solution, because the function of the Reply-To field is lost in important cases. A new Reply-To field that third parties are prohibited from munging would have to be defined. Why do that when we already have one?
Citation, please? I already quoted the part of RFC 2822 that shows that semantically speaking your assertion is incorrect.
From RFC 5322 (http://www.rfc-editor.org/rfc/rfc5322.txt), sec. 3.6.2:
The originator fields indicate the mailbox(es) of the source of the message. The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. [...]
The originator fields also provide the information required when replying to a message. When the "Reply-To:" field is present, it indicates the address(es) to which the author of the message suggests that replies be sent. In the absence of the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es) specified in the "From:" field unless otherwise specified by the person composing the reply.
In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message. See also section 3.6.3 for more information on forming the destination addresses for a reply.
The language in RFC 2822, section 3.6.2 is identical, or very close to it. Your interpretation of "originator" as "other end of the last hop" is specious. It's reasonable for users like you to delegate the use of Reply-To to the mailing list, but the mailing list is *not* the author in the case of discussion lists, and such delegation *must* be explicit, not assumed by the mailing list manager.
If there is an RFC that supersedes the definitions of RFC 2822, I'd like to see it. At present, I am not aware of one.
This information is generally available in the document rfc-index.txt, at the same base URL. For RFC 2822 it reads:
2822 Internet Message Format. P. Resnick, Ed.. April 2001. (Format: TXT=110695 bytes) (Obsoletes RFC0822) (Obsoleted by RFC5322) (Updated by RFC5335, RFC5336) (Status: PROPOSED STANDARD)
Regards,
Steve
On Oct 14, 2009, at 1:35 AM, Michael B. Trausch wrote:
There are two major uses of email, discounting automatically generated messages, corporate crap and spam: email from one person or to one person or a group of people, and email from one person to a mailing
list (presumably with people on it).
You need to at the coarsest break down the latter into sub-
categories. Mailing lists can be discussion lists like this one, or
"announce" (one-way) lists. Often, those latter lists want to funnel
further discussion to a second mailing list. I don't see how
selective Reply-To munging can support this use case.
However, the primary use-case for a mailing list is _group_ _discussion_. Or at least, so I thought. Call me silly, but if it's not meant to be group discussion as the primary role, maybe mailing lists should stop using server software and become ad-hoc, old boys' club style, personally shared and replicated distribution lists,
nothing more. Being that is the case, and that is what users of mailing lists _expect_, it is reasonable to assume that the way reply-to is handled would be thus:
Hyperbole aside, I don't believe this corresponds to what users
expect. People need to know intuitively and consistently what their
MUA buttons are going to do and will not hunt around in composition
fields to try to figure that out.
Mail.app for example has a Reply button and a Reply All button. I
think the most intuitive interpretation of those is that the former
replies to the author and the latter replies to all recipients (one of
which happens to be the mailing list). Breaking that contract will
piss people off and cause potentially serious damage, and doing so
unpredictably will make matters worse.
- I send an email to the mailing list to start a thread of discussion. I send no reply-to header on the message, so the list processing software appends one redirecting replies to the group. This
facilitates group discussion. It's not Orwellian, it's common sense---if, of course, we make the assumption that mailing lists are for, you know, group discussion and not private communication.
It also breaks your MUA.
If I want to communicate privately with someone, I won't be sending the mail to a mailing list; if I need to communicate with someone who is on a ML privately, and I don't have their address, that's what ML archives are for (or, sending a mail to the ML to ping them, or searching my own archives, if the public archives have that information stripped).
Have you never wanted to reply privately to the author of a mailing
message?
I do all the time, and even though I trust my MUA and most mailing
lists to be configured properly, I'm extremely anal about checking my
headers (and sometimes after the fact, even checking my Sent
folder ;). But I confidently state that this is aberrant behavior :)
Most normal people will just trust their buttons and hit send. The
damage this can cause is irreversible.
- During the course of the thread, it becomes clear that some
sensitive information must be sent (to address your use case from your Web page from earlier in this thread). That's totally not a problem: The
person asking for the sensitive information simply adds a reply-to header to their outbound message.
The problem with this analysis is that it's not the original sender
that gets to decide whether responses will contain sensitive
information or not, it's the person sending the reply.
Citation, please? I already quoted the part of RFC 2822 that shows
that semantically speaking your assertion is incorrect. If there is an RFC that supersedes the definitions of RFC 2822, I'd like to see it. At present, I am not aware of one. (Further, if there is additional clarification that I've missed in my readings of RFC 2822, I'd like a pointer to that, as well; I've already read it once today, maybe I'll review it again later for things I missed in today's reading.)
Here's what RFC 5322 $3.6.2 says:
"The originator fields also provide the information required when
replying to a message. When the "Reply-To:" field is present, it
indicates the address(es) to which the author of the message suggests
that replies be sent. In the absence of the "Reply-To:" field, replies
SHOULD by default be sent to the mailbox(es) specified in the "From:"
field unless otherwise specified by the person composing the reply."
There's no way that I can read that to suggest that the mailing list
has any right to touch that field. This language says to me that
Reply-To is firmly under the purview of the message's original author.
In my (admittedly, limited in terms of global and topical coverage) personal experience, _most_ mailing lists are poorly configured on the extreme of users not being able to specify a reply-to at all, because the reply-to is stripped and subsequently replaced by the mailing list software. Clearly, this is _bad_. Is it wrong? Not according to RFC 2822, because the mailing list processor is the logical origin of a message and thus it is clear to send the header---or not---as it sees fit.
I completely disagree. The MLM is not the "logical origin" of a
message.
However, what sparked this thread was a practical concern regarding a very common usage pattern, not a concern that everything
be 100% idealistic and precisely fit some standard as interpreted by
random person X.In other words, what we're talking about is left---according to the ambiguous text in RFC 2822---as an implementation detail of mailing
list processing software.
Again, I disagree with this interpretation.
-Barry
This thread is a perfect example; "Reply-All" in my MUA puts all these people on the destination list, even though I'm pretty sure they are all on the list itself. Enjoy your duplicates! And if one of you *isn't* on the list, then you should join.
Anyway, Barry asked:
Have you never wanted to reply privately to the author of a mailing message?
Of course. But it's not the common case; the common case is: continue the discussion, on-list. So you're wanting to do soemthing other than the default, so you should *have* to do something differently in order to accomplish it.
Mailing lists are different from other kinds of email; otherwise why have lists at all?
/jordan
On Wed, 2009-10-14 at 08:33 -0700, Jordan Hayes wrote:
Anyway, Barry asked:
Have you never wanted to reply privately to the author of a mailing message?
Of course. But it's not the common case; the common case is: continue the discussion, on-list. So you're wanting to do soemthing other than the default, so you should *have* to do something differently in order to accomplish it.
Mailing lists are different from other kinds of email; otherwise why have lists at all?
Exactly.
I've also needed to reply privately. I find it _far_ easier to remove addresses from the To: bar than it is to look them up and add them. Of course, that's just me: I'm not über-1337 or anything like that, so I don't have an SQLite database or 30 in my head.
See my reply from a few moments ago for (the start of!) an idea that might make sense in today's technological environment and aims to please both ends of the spectrum, including people close to the middle such as myself.
--- Mike-- Blog: http://mike.trausch.us/blog/ Misc. Software: http://mike.trausch.us/software/
“The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.” —Michelangelo
Michael B. Trausch wrote:
Whether the emails are in a personal, hobbyist, collegiate, educational, or professional context, the patterns are largely the same. In both events, 95+% of the time, there is no reply-to header attached by the authors MUA.
Where do you get this statistic. I have no hard data, but I think it's doubtful. I see lots of mail generated with a Reply-To: containing the same address as the From: because the MUA's account wizard offers a reply-to field and the clueless user fills it in and all their mail is sent with a Reply-To: header.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Oct 13, 2009, at 7:15 PM, Michael B. Trausch wrote:
I would say that if ML software _always_ overrides reply-to, even when the author explicitly provided one, then that is broken.
Aside from the other problems that have been pointed out, selectively
overriding Reply-to makes the mailing list behavior almost impossible
to predict. Whatever the legitimate pros and cons for always munging
or never munging, at least it's predictable without the user having to
hunt around in the Reply-To or being ultra-careful with their Send
button, neither of which will happen for Real Users in the real world.
Even better, this eliminates the problem of:
I post message A without reply-to:
To: ml@example.org From: mbt@zest.trausch.us
Someone responds with message B and hits reply-all, also without reply-to:
To: mbt@zest.trausch.us Cc: ml@example.org From: user@example.org
And then I don't get a message with a List-Post header _at all_. That is one failing that your algorithm cannot fix, unless the ML sends its second copy (and most MLs are configured not to do so, because users find it inconvenient).
Mailman leaves it up to the user to suppress the list copy if they are
explicitly named on a recipient header. The downside of course is
that the mailing list cannot suppress the off-list copy because it
never sees it, so the only possibility is to suppress the copy with
all the helpful mailing list bling.
Of course, you can always use an MUA such as Gmail that "helpfully"
suppresses messages with duplicate Message-IDs. I put that in quote
because it's a FAQ that Gmail users never even see the list-copy of
their own postings, and they often don't know if their message made it
to the list.
-Barry
participants (7)
-
Barry Warsaw -
Ben Finney -
Jordan Hayes -
Mark Sapiro -
Michael B. Trausch -
Stephen J. Turnbull -
Stephen J. Turnbull