On 01/24/2018 09:16 PM, Jordan Brown wrote:

I don't understand this statement. Or, I don't understand how it disagrees with what I said. I don't really care whether the MUA has a "Reply List" button that does something list-specific. "Reply" should go to the author; "Reply All" should go to all of the original recipients.

It's been a long day, let's just move past.

Of course, and I'm free to participate or not participate in mailing lists based on their policies. And although I normally try to resist this argument (and don't always succeed), somebody explicitly suggested trying to define a best practice... and if there's ever a time to say what one thinks the best practice should be, that's it.

That logic seems reasonable to me.

Sure. That's what "Reply All" means. Like you said, it's a matter of user education

There is a distinct difference in replying to all and replying to the list. Namely the list is a subset of all.

Let's look at a couple of e-mail messages. (And not bothering to put in real addresses, or the headers that the mailing list might magically add.)

From: Sam
To: Joe, Dave, Jordan

If I hit Reply, the message goes to Sam. If I hit Reply All, the message goes to Sam, Joe, and Dave. (And maybe, depending on my MUA, to me too.)

Any controversy there?

Nope.

Now the second message:

From: Sam
To: MailingList

In the scheme I prefer: If I hit Reply, the message goes to Sam. If I hit Reply All, the message goes to Sam and the mailing list. This seems totally consistent with the behavior above.

Sure.

In the scheme you prefer (as I understand it): If I hit Reply, the message goes to the mailing list. If I hit Reply All, the message goes to the mailing list.

Using the pseudo headers you provided, hitting Reply would go back to Sam. If there was a Reply-To header, and it was set to the mailing list, the message would go to the mailing list.

There's no way to get the message to go just to Sam (absent cutting and pasting). If Sam isn't on the mailing list, he won't even get a copy.

Based on how I think /discussion/ mailing lists /should/ operate, I'm perfectly fine with that. I'd go so far as to say that /discussion/ mailing lists could remove any and all From / Reply-To / To / Sender / et al headers from the message. - I think the message that I receive as a mailing list subscriber /should/ be /from/ /the/ /list/. (I'm distinctly ignoring any copy that comes to me as a To / CC / BCC as I tend to ignore them and only act on the copy from the mailing list.)

I view the mailing list as an entity that is originating the copy that I receive. As such, my replies should go back to said entity.

Note: This is my opinion of /discussion/ mailing lists. - Broadcast lists (a.k.a. expansion lists) are different and should make no modification to the message content at all.

But most importantly, the behavior is not consistent with the non-mailing-list behavior above.

I think this behavior is perfectly consistent with my view of /discussion/ mailing lists.

Now another message:

From: Sam
To: MailingList, Joe, Dave, Jordan

In my scheme, again, Reply goes to Sam; Reply All goes to everybody. Consistent with the behavior above.

In your scheme, Reply goes to ... ? Well, it depends. If this is the copy of the message that I got through the mailing list, Reply will go to the mailing list, Joe, and Dave.

It will depend on how the mailing list is configured. In my ideal scenario for a /discussion/ mailing list, the reply would /only/ go to the mailing list.

If, on the other hand, this is the copy that I got directly, Reply will go to Sam. Reply All goes to... if it's the mailing list copy, it goes to the mailing list, Joe, and Dave; if it's the direct copy, then Sam, the mailing list, Joe, and Dave. For the two replies based on the mailing list copy, the message won't go to Sam unless he's on the mailing list.

I feel sorry for Sam and think that he should subscribe to the mailing list. But s/he has that option.

And another:

From: Sam
To: MailingListA, MailingListB

For fun, let's assume that I'm on both mailing lists.

Okay.

My scheme: Reply goes to Sam; Reply All goes to Sam and both mailing lists. Consistent with the behavior above.

Your scheme: Reply: If this is the copy I got through list A, it goes to list A; if it's the copy I got through list B, it goes to list B. Reply All: goes to both mailing lists. Only goes to Sam if he's on one of the mailing lists.

Sure.

Now, when you consider all of those cases, which scheme is simpler and easier to understand? Which is less likely to have messages going to unexpected groups of people, when you spend all day responding to a mix of all of the types?

I understand your logic. It seems reasonable enough. I still disagree with it. - By the way the sun is purple. ;-) We can agree to disagree.

And yes, those are all very real cases. I expect that if I go through my work e-mail for the last day I'll find examples of each, and I would be virtually certain if I looked through a week. (And that includes the "Sam isn't a member of the mailing list" variants; those are *very* common.)

I don't doubt what you're saying.

I do question how many of those are /discussion/ mailing lists like I've outlined above.

Yes, that's a nuisance, but I think it's not nearly as bad as the alternatives. It costs me a tap of the Delete key; it doesn't send my private criticism of the author to his boss.

Sure.

What's really needed there is a MUA that hides duplicates, though that's tricky when mailing list software munges the message and the headers.

Please clarify what is duplicated that you'd like to see hidden?

If you, the author, really want replies that I intend to be private going to the mailing list, yes, of course you can set Reply-To... and the mailing list software should leave that alone.

I hear and understand what you're saying. I think that at least a tiny bit of responsibility is on you to check the address that the message is going to. It may be 1%, or more, or less, but I do believe that you as a sender have a responsibility to check where you are sending the email to.

It's not a driver's fault if a driver from the oncoming lane swerves into the first driver's lane. But it is the first driver's responsibility to try to avoid the obstacles that have suddenly appeared in front of him / her, or at least make an effort to do so.

I'm not going to be happy with you when I embarrass both of us by using the reply habits that work for non-mailing-list mail to reply privately, and it goes to a group. You might not be happy with me either, but you'll get precisely zero sympathy from me; you set it up that way.

I think that's fair.

Somebody - whether it's you as the author, or the mailing list software - who sets Reply-To to point to the mailing list, is deliberately causing *my* replies to go to someplace that I didn't want them to go to, that I didn't expect them to go to based on all of my habits for non-mailing-list mail (and the majority of mailing-list mail).

I'm not setting where the messages /do/ go. I'm setting where I would /like/ the messages to go. You, as the reply author are responsible for what your MUA sends.

*You* shouldn't be saying where *my* reply goes.

I'm /not/ saying where your reply /does/ go. I'm saying where I would /like/ it to go.

-- Grant. . . . unix || die

Jordan Brown writes:

You were complaining that in some list configurations you will tend to get multiple copies of a message - one directly to you, and one via the list.

I was suggesting that one way to address that complaint would be for your mail client to detect the duplication and hide the duplicate copies.

One convention that was used a lot on one of the dev lists I participated in was that explicitly addressing a senior dev meant you needed *their* attention and *soon*. Suppressing either would be suboptimal (they ended up getting saved in different folders for most of us, and especially as listmaster, *I* wanted the list copies). (BTW, people who reply-all'd to such messages ended up in a lot lof killfiles, everybody happy!)

...

I'm /not/ saying where your reply /does/ go.  I'm saying where I would /like/ it to go.

Mostly, I'd say that you've already said that by including the mailing list in the To or CC list.  When I reply to a message with multiple recipients (however those recipients might be specified), I'd say that the normal convention is to include all of them in any ongoing discussion by hitting Reply All.

That's "normal" mostly because, like you, most people think that a few seconds cleaning up a reply-all list is way too much effort. But that habit being widespread certainly means that some people with no interest in the conversation end up in the canoe with you, merely because they posted to a mailing list at some point. Many of these same people think that almost all replies to a list post should be directed to the list. That combination certainly accounts for some of the strength of support for Reply-To munging.

 > If you wanted your message to go to the mailing list but didn't > want replies to go there, you could have put the mailing list into > the BCC.

These days, you mostly can't. BCC'd mailing lists mostly assume you're a spammer.

-- Associate Professor Division of Policy and Planning Science http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN

On 01/30/2018 02:33 PM, Grant Taylor via Mailman-Users wrote:

...  I'm also not aware of much that Thunderbird can do.

There is/was a plug-in for finding duplicates. It only works if you have both, if you already deleted the off-list copy that's no different from what you get with procmail.

Dep. on your MDA setup, list replies could go to list folder and off-list copies: to main inbox. In which case I think that thunderbird plug-in would not work either, even if you still have both on disk.

-- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

On 01/30/2018 03:27 PM, Grant Taylor via Mailman-Users wrote:

About the only thing that I can think to do would be to have my LDA deliver a copy of the post from the mailing list to a script that would search the Inbox for messages with the same Message-ID and then retroactively remove them.

Does it ave the same Message-ID though? I suppose if I reply-both on this one, you'll have an easy way to check.

(sending to both)

Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

On 1/30/2018 2:09 PM, Dimitri Maziuk wrote:

The only problem then is list mail will seldom land in the list sub-folders as the direct replies should almost always come first and land in inbox.

That depends entirely on how you design your filters.  My Mailman filter looks for From, To, CC, or BCC containing mailman-users@python.org.  It could also reasonably look for Envelope-To[*] containing mailman@jordan.maileater.net, which would also capture private Mailman-related conversations, but I haven't had enough of those to bother.

[*] Added by my MTA on receipt.

And PPS my maildropex(7) has

''' Check if the Message-ID: header in the message is identical to the same header that was recently seen. Discard the message if it is, otherwise continue to filter the message:

       ‘reformail -D 8000 duplicate.cache‘
       if ( $RETURNCODE == 0 )
           exit

   The reformail[1] command maintains a list of recently seen

Message-IDs in the file duplicate.cache. '''

-- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

On 01/30/2018 02:43 PM, Grant Taylor via Mailman-Users wrote:

On 01/30/2018 03:02 PM, Dimitri Maziuk wrote:

...

Does it ave the same Message-ID though? I suppose if I reply-both on this one, you'll have an easy way to check.

Yes, they frequently do have the same Message-ID.  About the only time they don't is if the MLM changes the Message-ID.

Which Mailman doesn't do except for posts to anonymous lists (for privacy reasons) and posts gated to Usenet (for reasons having to do with potential cross-posting to multiple lists that gate to Usenet but to different news groups.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 02/05/2018 12:22 AM, Stephen J. Turnbull wrote:

According to RFC, Message-ID is an originator field, and MUST be present and MUST be unique.

Do you have a reference for this? I thought this was correct, but I recently looked it up in RFC 5322 and predecessors (see <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/U...>, and those RFCs at least say it's optional and SHOULD be present.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Dimitri Maziuk writes:

Heh. I personally believe that a message sent by a mailing list *must* have the mailing list as the originator: dkim, id, and whatever else.

First, please be careful with terminology. *Originator* is well-defined (RFC 5598) as the agent of the Author that first injects the message into the mail system. When mailing lists distribute posts to subscribers, they function as *Mediators* (RFC 5598).

Even if used loosely, I see no reason here to think of mailing lists as "originators". DKIM explicitly provides that multiple signatures may be present, whether from the same host or different hosts. For message identification, Mediators are encouraged to use Resent-Message-ID and other Resent-* fields to provide trace information in addition to the MTA's Received fields. Such features are available to any agent in the mail system, not restricted to Authors and Originators.

And even if "Message-ID MUST be present and MUST be unique", that doesn't make the converse true: that two copies of the same message *must* carry the same Message-ID.

I don't understand your point. The RFCs make clear that in the case of certain trivial modifications (adding trace fields to the header, for example), the Message-ID SHOULD be preserved. Further, Mark has described when Mailman will alter the Message-ID, and I described some of the cases where people disagree about whether to alter it.

However, for stock Mailman, I think that pretty much everybody who cares about Message-ID agrees that given the kinds of changes Mailman makes to messages, it should only change Message-ID in an overriding case such as preserving privacy on a list that purports to anonymize posts, or where it interferes with interoperability. Otherwise you interfere with features such as local duplicate suppression, threading, and archiving that depend on stability of Message-ID.

Do you have something to add to that, or disagree with that?

Steve

Mark Sapiro writes:

On 02/05/2018 12:22 AM, Stephen J. Turnbull wrote:

...

According to RFC, Message-ID is an originator field, and MUST be present and MUST be unique.

Do you have a reference for this? I thought this was correct, but I recently looked it up in RFC 5322 and predecessors and those RFCs at least say it's optional and SHOULD be present.

You're right. I knew that it was SHOULD in RFC 822, but I thought this was updated in RFC 1123 "Host Requirements" or maybe RFC 5598 "Email Architecture". I was wrong.

In any case, SHOULD is pretty close to MUST, especially in this case. (What reasons based on interoperability issues can you think of for omitting Message-ID? SHOULD means you need one!)

I'm guessing that since the RFC authors have deprecated use of Message-ID for anything related to security, and its semantics are a judgment call in any case, it's simply not reliable enough to promote to MUST. So they never did.

Steve