[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 - 3.3-p6?)
On Wed, 17 Apr 2013, Jed Brown wrote: John Doe sends email to petsc-users and the mailing list rewrites Reply-To back to the list. Now any user hits reply-all and their mailer gives them a message that replies *only* to petsc-users, dropping the original author. This is a problem, Its a problem only if the author is not subscribed. and only a few mailers have a when From and Reply-To do not agree, assume this is mailing list munging and disregard the intent of the Reply-To field (RFC 2822) by also replying to the address found in From feature. In other words, any mailer that interprets the Reply-To field as its intended instead of semantics rather than in addition to will drop the original author, meaning lost replies for people that are not subscribed or have delivery disabled. Or remove option 'subscribe-but-do-not-deliver' for our usage of 'Reply-To: list' Perhaps a middle ground would be to have the list copy the From header over to Reply-to (if it doesn't already exist) and then _add_ the list address to Reply-to. That still isn't quite right when cross-posting, but it would allow us to advertise subscribe with delivery off and ask questions on the list or even mail the list without subscribing instead of always write petsc-maint if you can't be bothered to filter the high-volume list. Earlier in the thread you've supported: reminder emails to folks doing 'reply' instead of 'reply-all:' as an acceptable thing. [and this happens a few times a day]. But here a reply of 'use petsc-maint' instead of subscribe-but-do-not-deliver with petsc-users' is suggested not good. [which happens so infrequently - except for configure.log sutff]. And I fail to see how 'e-mail petsc-maint without subscribing is not good - whereas 'email petsc-users without subscribing is a great feature'. [yeah you get archives on petsc-users - but I don't think uses are as much concerened about that.] And I'll submit - its easier for most folks to send email to petsc-maint instead of figuring out 'subscribe-but-donot-deliver stuff on petsc-users'. [Yeah 'expert' mailing list users might expect subscribe with delivery workflow to work.] Perhaps the problem here is - I view petsc-users and petsc-dev as public mailing lists - and primary purpose of public mailing lists is all to all communication mechanism. [so subscription/ reply-to make sense to me.] And petsc-maint as the longstanding non-subscribe/support or any type of conversation e-mail to-petsc-developers. But most use petsc-users [and some view it] as a support e-mail adress [with searchable archives]. If thats what it it - then no-subscribe-post or subscribe-but-do-not-deliver stuff would be the primary thing - and recommending that would make sense. And then we should be accepting build logs on it as well - and not worry about flooding users mailboxes iwth them. [compressed as openmpi list recommends] [what about petsc-dev? some use it as reaching petsc-developers - not petsc development discussions. And what about petsc-maint? redirect to petsc-users and have petsc-developers an non-ambiguous place for non-public e-mails to petsc-developers?] Satish
[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 - 3.3-p6?)
Satish Balay balay at mcs.anl.gov writes: On Wed, 17 Apr 2013, Jed Brown wrote: John Doe sends email to petsc-users and the mailing list rewrites Reply-To back to the list. Now any user hits reply-all and their mailer gives them a message that replies *only* to petsc-users, dropping the original author. This is a problem, Its a problem only if the author is not subscribed. If they are not subscribed OR if they have turned off delivery. Even with delivery turned on, they cannot reliably filter using petsc-users AND NOT to:me because their address will be chronically dropped. This makes the list volume more burdensome. Or remove option 'subscribe-but-do-not-deliver' for our usage of 'Reply-To: list' That is back to the current model where (I think) many people ask questions on petsc-maint just because it's more effort/noise to be subscribed to petsc-users with delivery turned on. Perhaps a middle ground would be to have the list copy the From header over to Reply-to (if it doesn't already exist) and then _add_ the list address to Reply-to. That still isn't quite right when cross-posting, but it would allow us to advertise subscribe with delivery off and ask questions on the list or even mail the list without subscribing instead of always write petsc-maint if you can't be bothered to filter the high-volume list. Earlier in the thread you've supported: reminder emails to folks doing 'reply' instead of 'reply-all:' as an acceptable thing. [and this happens a few times a day]. But here a reply of 'use petsc-maint' instead of subscribe-but-do-not-deliver with petsc-users' is suggested not good. [which happens so infrequently - except for configure.log sutff]. I think almost nobody uses subscribe-without-delivery to petsc-users/petsc-dev because it's useless with the current reply-to munging. I reply to the other point below. And I fail to see how 'e-mail petsc-maint without subscribing is not good - whereas 'email petsc-users without subscribing is a great feature'. [yeah you get archives on petsc-users - but I don't think uses are as much concerened about that.] Each time someone resolves their problem by searching and finding an answer in the archives is one less time we have to repeat ourselves. The lists are indexed by the search engines and they do come up in searches. When a subject has already been discussed, linking a user to that thread is much faster than retyping the argument and it encourages them to try searching before asking. My perception is that a lot of questions come up more than once on petsc-maint. We can only link them to the archives if it has already been discussed on petsc-users, and with so many discussions on petsc-maint, it's hard for us to keep track of whether the topic has been discussed. And I'll submit - its easier for most folks to send email to petsc-maint instead of figuring out 'subscribe-but-donot-deliver stuff on petsc-users'. [Yeah 'expert' mailing list users might expect subscribe with delivery workflow to work.] Which is why we would encourage them to write petsc-users, either via an easy subscribe-without-delivery, or by having their original message only go to a few of us, where a reply from any of us automatically subscribes them without delivery. If the list interpreted any mail from a subscribed user as subscribing the Cc's without delivery, we could also move discussions from petsc-maint to petsc-users/petsc-dev any time the discussion does not need to be kept private. Perhaps the problem here is - I view petsc-users and petsc-dev as public mailing lists - and primary purpose of public mailing lists is all to all communication mechanism. [so subscription/ reply-to make sense to me.] And petsc-maint as the longstanding non-subscribe/support or any type of conversation e-mail to-petsc-developers. I've always thought of petsc-maint as the intentionally _private_ help venue. If the conversation does not have a good reason to be private, then I'd rather see it on a public (searchable) list. But most use petsc-users [and some view it] as a support e-mail adress [with searchable archives]. If thats what it it - then no-subscribe-post or subscribe-but-do-not-deliver stuff would be the primary thing - and recommending that would make sense. And then we should be accepting build logs on it as well - and not worry about flooding users mailboxes iwth them. [compressed as openmpi list recommends] I wonder if we can do either (a) selective delivery of attachments greater than some small threshold and/or (b) create a [config] topic that people can unsubscribe from. (Maybe leave unsubscribed by default.) http://www.gnu.org/software/mailman/mailman-member/node30.html [what about petsc-dev? some use it as reaching petsc-developers - not petsc development discussions. I don't think that's a problem. And what about petsc-maint? redirect to petsc-users and have petsc-developers an non-ambiguous place for
[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 - 3.3-p6?)
On Thu, 18 Apr 2013, Jed Brown wrote: Satish Balay balay at mcs.anl.gov writes: On Wed, 17 Apr 2013, Jed Brown wrote: John Doe sends email to petsc-users and the mailing list rewrites Reply-To back to the list. Now any user hits reply-all and their mailer gives them a message that replies *only* to petsc-users, dropping the original author. This is a problem, Its a problem only if the author is not subscribed. If they are not subscribed OR if they have turned off delivery. As mentioned this is a mailing list. And that 'minority' usage is possible with alternative workflow. subscribe and use a filter. Even with delivery turned on, they cannot reliably filter using petsc-users AND NOT to:me because their address will be chronically dropped. This makes the list volume more burdensome. Again 'minority usage. Since one would not care about following list except for 'when they post' - They would filter list traffic into a different folder - and look at that folder only when they post to that list. As I claimed the usage is possible [for the minority use case]. Its insisting that the 'exact workflow' as with 'non-reply-to: lists' should be supported is not what I accept. Or remove option 'subscribe-but-do-not-deliver' for our usage of 'Reply-To: list' That is back to the current model Whih I think is fine - and optimized for majority usage. And change has extra costs [which you are ignoring. where (I think) many people ask questions on petsc-maint just because it's more effort/noise to be subscribed to petsc-users with delivery turned on. using petsc-maint is fine. But here you are suggesting using petsc-maint should be discouraged. Perhaps a middle ground would be to have the list copy the From header over to Reply-to (if it doesn't already exist) and then _add_ the list address to Reply-to. That still isn't quite right when cross-posting, but it would allow us to advertise subscribe with delivery off and ask questions on the list or even mail the list without subscribing instead of always write petsc-maint if you can't be bothered to filter the high-volume list. Earlier in the thread you've supported: reminder emails to folks doing 'reply' instead of 'reply-all:' as an acceptable thing. [and this happens a few times a day]. But here a reply of 'use petsc-maint' instead of subscribe-but-do-not-deliver with petsc-users' is suggested not good. [which happens so infrequently - except for configure.log sutff]. I think almost nobody uses subscribe-without-delivery to petsc-users/petsc-dev because it's useless with the current reply-to munging. I reply to the other point below. I doubt most users know about subscribe-without-delivery option of mailing lists. And I think most users think petsc-users as not a mailing list - but as petsc-maint. And I fail to see how 'e-mail petsc-maint without subscribing is not good - whereas 'email petsc-users without subscribing is a great feature'. [yeah you get archives on petsc-users - but I don't think uses are as much concerened about that.] Each time someone resolves their problem by searching and finding an answer in the archives is one less time we have to repeat ourselves. The lists are indexed by the search engines and they do come up in searches. When a subject has already been discussed, linking a user to that thread is much faster than retyping the argument and it encourages them to try searching before asking. My perception is that a lot of questions come up more than once on petsc-maint. We can only link them to the archives if it has already been discussed on petsc-users, and with so many discussions on petsc-maint, it's hard for us to keep track of whether the topic has been discussed. I don't object to more archiving of issues. And I'll submit - its easier for most folks to send email to petsc-maint instead of figuring out 'subscribe-but-donot-deliver stuff on petsc-users'. [Yeah 'expert' mailing list users might expect subscribe with delivery workflow to work.] Which is why we would encourage them to write petsc-users, either via an easy subscribe-without-delivery, or by having their original message only go to a few of us, where a reply from any of us automatically subscribes them without delivery. I already do the second part with the current mailing lists. [plenty of users post without subscribing every day - which goes into moderation. I appprove/subscribe that post.] If the list interpreted any mail from a subscribed user as subscribing the Cc's without delivery, we could also move discussions from petsc-maint to petsc-users/petsc-dev any time the discussion does not need to be kept private. I agree this usage is not supported currently. [but I don't know if that automatic-cc-subscribe-as-without-delivery is possible] Perhaps the problem here is - I view petsc-users and petsc-dev as public mailing lists - and primary
[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 - 3.3-p6?)
Satish Balay balay at mcs.anl.gov writes: Again 'minority usage. Since one would not care about following list except for 'when they post' - They would filter list traffic into a different folder - and look at that folder only when they post to that list. The problem is that you have to monitor _everything_ and you have to draw a line after sending a message when you decide to stop paying attention (changing your filters or not checking that folder). With reply-all convention, you just email and rest assured that all messages relevant to you will continue to Cc you. using petsc-maint is fine. But here you are suggesting using petsc-maint should be discouraged. Yes, the reason is that our effort does not scale well and has no historical value when it happens on petsc-maint. On an archived and searchable mailing list, we can refer to old discussions and it's more open in that people who are not core developers can participate. I doubt most users know about subscribe-without-delivery option of mailing lists. And I think most users think petsc-users as not a mailing list - but as petsc-maint. Hmm, I would think that most users know petsc-users is a mailing list. I agree this usage is not supported currently. [but I don't know if that automatic-cc-subscribe-as-without-delivery is possible] Does the list configuration have an API? If so, we could have a bot monitoring petsc-users email and subscribing (without delivery) addresses that are Cc'd in approved messages? the whole argument is more archives and email-without subscribing. I don't buy the stuff about subscribe with delivery or reply-to is breaking stuff. What part don't you buy? If someone writes to the list, reply-all from another list subscriber goes only to the list. That means they can't distinguish mail that they are interested in from all the other stuff on the list. I hypothesize that a lot of people write petsc-maint because they don't like the firehose implied by using petsc-users. Turning off munging fixes the firehose problem. The reason to prefer petsc-users when possible is searchability/archives. And the cost is more replies going to individuals. We already have this on petsc-maint, but asking for the author to resend (which teaches them) is more justifiable on an archived list because it provides understandable value. And some extra spam. When you approve a message, are you whitelisting the thread or the author? If the author, it's equivalent to subscribe-without-delivery. Maybe that is good enough? And huge logs to subscribers. [and advertise petsc-users as support list - not mailing list]. Scrubbing large attachments is fine as long as we can deliver them to people who opt in, or at least those who are currently on petsc-maint. I don't know if there is an option for that. Currently all moderators get such emails. There is a difference between list moderator and admin, right? Can the current petsc-maint group be labeled as moderator so that we get the attachments? But the user has to set the correct topic in the subject line when they post? Again transfering decision from 'use petsc-users vs petsc maint' to use subject: 'installation' vs 'bugreport' vs 'general'. We can just add [installation] to the subject line when we reply so that users don't see the reply threads for untagged messages. The main disadvantage would be that it would look like we weren't replying to those messages. This may not be worthwhile.
[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 - 3.3-p6?)
On Thu, 18 Apr 2013, Jed Brown wrote: Satish Balay balay at mcs.anl.gov writes: Again 'minority usage. Since one would not care about following list except for 'when they post' - They would filter list traffic into a different folder - and look at that folder only when they post to that list. The problem is that you have to monitor _everything_ and you have to draw a line after sending a message when you decide to stop paying attention (changing your filters or not checking that folder). With reply-all convention, you just email and rest assured that all messages relevant to you will continue to Cc you. Sure - there is cost for 'minority users. But to save that - you propose a cost to majority users [i.e everyone should conciously use 'reply-all'] Does the list configuration have an API? If so, we could have a bot monitoring petsc-users email and subscribing (without delivery) addresses that are Cc'd in approved messages? you can check that. the whole argument is more archives and email-without subscribing. I don't buy the stuff about subscribe with delivery or reply-to is breaking stuff. What part don't you buy? If someone writes to the list, reply-all from another list subscriber goes only to the list. That means they can't distinguish mail that they are interested in from all the other stuff on the list. see above I hypothesize that a lot of people write petsc-maint because they don't like the firehose implied by using petsc-users. Turning off munging fixes the firehose problem. I submit that most petsc-maint users are familiar with petsc-maint - and continue to use it. New users do get confused between petsc-users petsc-maint When you approve a message, are you whitelisting the thread or the author? If the author, it's equivalent to subscribe-without-delivery. Maybe that is good enough? I've been doing subscribe-with-delivery. Scrubbing large attachments is fine as long as we can deliver them to people who opt in, or at least those who are currently on petsc-maint. Not sure if its possible to scrub just the attachments. If thats possible you can now configure mailman to do that. I don't know if there is an option for that. Currently all moderators get such emails. There is a difference between list moderator and admin, right? Can the current petsc-maint group be labeled as moderator so that we get the attachments? Sure - you can set that up now. Satish
[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 - 3.3-p6?)
Satish Balay balay at mcs.anl.gov writes: Sure - there is cost for 'minority users. But to save that - you propose a cost to majority users [i.e everyone should conciously use 'reply-all'] That has always been standard mailing list etiquette. Does the list configuration have an API? If so, we could have a bot monitoring petsc-users email and subscribing (without delivery) addresses that are Cc'd in approved messages? you can check that. Hmm, I couldn't find it. Not sure if its possible to scrub just the attachments. If thats possible you can now configure mailman to do that. It looks like we can do it, but not from the web interface: http://wiki.list.org/pages/viewpage.action?pageId=7602227 One option would be to apply a good compression like lzma/xz to configure.log attachments. That brings a 5MB log file down to 160 kB. PETSc could compress configure.log up-front, but then you have to use xzless to look at it and not many people know to do that. I don't know if there is an option for that. Currently all moderators get such emails. There is a difference between list moderator and admin, right? Can the current petsc-maint group be labeled as moderator so that we get the attachments? Sure - you can set that up now. Okay, I set up two topics: * installation * methods The former currently matches 'configure.log|make.log' and the latter matches the following which should be almost all generally interesting threads. method |converge |diverge |solver |solving |performance |usage |poisson |stokes |elasticity |compressible |flow |preconditioner |krylov |domain Let's see how well this classifies. If it is accurate, we can mention that people are welcome to unsubscribe from [installation], and possibly change the defaults.
[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 - 3.3-p6?)
Satish Balay balay at mcs.anl.gov writes: On Wed, 17 Apr 2013, Jozsef Bakosi wrote: Can you guys please CC jbakosi at lanl.gov? Thanks, J Mailing lists are setup that way. The default is: subscribe to participate, and reply-to: list. So cc:ing automatically doesn't work. If everyone used mailers that did group replies correctly, then we would always preserve Cc's in list discussions and the list would not munge the Reply-to header. Then people could subscribe and turn off list mail, or they could filter all mail to the list that didn't directly Cc them. This is a great way to manage high-volume mailing lists. You can even allow anonymous posting to the mailing list, which is what the Git list and many other open source/technical lists do. This is ruined by munging Reply-to because many/most mailers drop the From address in a group-reply when Reply-to is set. http://www.unicom.com/pw/reply-to-harmful.html http://woozle.org/~neale/papers/reply-to-still-harmful.html The problem is that an awful lot of mailers/users don't automatically do group replies to mailing list messages, causing the list Cc to be dropped. We have this problem with petsc-maint in that several emails per day are reminding people to keep petsc-maint Cc'd in the reply. Personally, I would rather turn off Reply-to munging and use a canned reply instructing users to resend their email to the list with all Cc's included (i.e., use reply-all when replying to the list). Almost all mailers can be configured to make this the default. I think this change would cause more people to ask questions on the mailing list where it becomes searchable than on petsc-maint where the reply helps only one person. Satish argued the other way when we discussed this a few years ago: http://lists.mcs.anl.gov/pipermail/petsc-dev/2010-March/002489.html
[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 - 3.3-p6?)
On Wed, 17 Apr 2013, Jed Brown wrote: Satish Balay balay at mcs.anl.gov writes: On Wed, 17 Apr 2013, Jozsef Bakosi wrote: Can you guys please CC jbakosi at lanl.gov? Thanks, J Mailing lists are setup that way. The default is: subscribe to participate, and reply-to: list. So cc:ing automatically doesn't work. If everyone used mailers that did group replies correctly, then we would always preserve Cc's in list discussions and the list would not munge the Reply-to header. Then people could subscribe and turn off list mail, or they could filter all mail to the list that didn't directly Cc them. This is a great way to manage high-volume mailing lists. You can even allow anonymous posting to the mailing list, which is what the Git list and many other open source/technical lists do. This is ruined by munging Reply-to because many/most mailers drop the From address in a group-reply when Reply-to is set. http://www.unicom.com/pw/reply-to-harmful.html http://woozle.org/~neale/papers/reply-to-still-harmful.html The problem is that an awful lot of mailers/users don't automatically do group replies to mailing list messages, causing the list Cc to be dropped. We have this problem with petsc-maint in that several emails per day are reminding people to keep petsc-maint Cc'd in the reply. Personally, I would rather turn off Reply-to munging and use a canned reply instructing users to resend their email to the list with all Cc's included (i.e., use reply-all when replying to the list). Almost all mailers can be configured to make this the default. I think this change would cause more people to ask questions on the mailing list where it becomes searchable than on petsc-maint where the reply helps only one person. Satish argued the other way when we discussed this a few years ago: http://lists.mcs.anl.gov/pipermail/petsc-dev/2010-March/002489.html Yes - and I still stand by that argument. Its best to otimize for 'majority usage' pattern. I know you deal with personal replies for petsc-maint stuff. But I set up my mailer to automatically set Reply-to:petsc-maint for all petsc-maint traffic [and modify it manually for the 1% usage case where thats not appropriate] And wrt anonymous posts [without subscribing] - that was a receipie for spam. [however good the spam filters are] - so you'll have to account for that crap aswell. We get plenty of that on petsc-maint - but now with petsc-users mailing list - that spam gets distributed to all list subscribers. Satish
[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 - 3.3-p6?)
Satish Balay balay at mcs.anl.gov writes: I know you deal with personal replies for petsc-maint stuff. But I set up my mailer to automatically set Reply-to:petsc-maint for all petsc-maint traffic [and modify it manually for the 1% usage case where thats not appropriate] If I only set Reply-to, then Gmail's reply does not reply correctly This seems buggy, but it's common and they never fix bugs so it doesn't help. Your headers set both: From: Satish Balay petsc-maint at mcs.anl.gov Reply-To: petsc-maint petsc-maint at mcs.anl.gov Several of us sending email as petsc-maint mixes up a lot of address books and Gmail will not allow me to send mail that way because Matt already claimed it and Gmail won't let two users send via the same address. So I would have to configure my outgoing smtp via mcs.anl.gov for those messages. (Not a problem, except when on networks that I have to proxy just to reach mcs.anl.gov.) And wrt anonymous posts [without subscribing] - that was a receipie for spam. [however good the spam filters are] - so you'll have to account for that crap aswell. We get plenty of that on petsc-maint - but now with petsc-users mailing list - that spam gets distributed to all list subscribers. Yeah, it happens occasionally, but it's easier to filter with the original headers intact.
[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 - 3.3-p6?)
On Wed, 17 Apr 2013, Jed Brown wrote: Satish Balay balay at mcs.anl.gov writes: I know you deal with personal replies for petsc-maint stuff. But I set up my mailer to automatically set Reply-to:petsc-maint for all petsc-maint traffic [and modify it manually for the 1% usage case where thats not appropriate] If I only set Reply-to, then Gmail's reply does not reply correctly This seems buggy, but it's common and they never fix bugs so it doesn't help. Your headers set both: From: Satish Balay petsc-maint at mcs.anl.gov If from is a problem [and messesup anyones mailboxes] - I can change that. I felt it was best to deal with it as petsc-maint completely. Reply-To: petsc-maint petsc-maint at mcs.anl.gov Several of us sending email as petsc-maint mixes up a lot of address books and Gmail will not allow me to send mail that way because Matt already claimed it and Gmail won't let two users send via the same address. No such problem from pine [even though most of you think its an antique tool for current times] So I would have to configure my outgoing smtp via mcs.anl.gov for those messages. (Not a problem, except when on networks that I have to proxy just to reach mcs.anl.gov.) Any smtp server should be fine. [but I guess if one doesn't work - all won't work]. I usually tunnel imap/smtp over ssh [eventhough is not required for smtp]. But you do go to places with blocked ssh - so that doesn't help. Satish And wrt anonymous posts [without subscribing] - that was a receipie for spam. [however good the spam filters are] - so you'll have to account for that crap aswell. We get plenty of that on petsc-maint - but now with petsc-users mailing list - that spam gets distributed to all list subscribers. Yeah, it happens occasionally, but it's easier to filter with the original headers intact.
[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 - 3.3-p6?)
Satish Balay balay at mcs.anl.gov writes: If from is a problem [and messesup anyones mailboxes] - I can change that. I felt it was best to deal with it as petsc-maint completely. This will cause the problem I mentioned because Reply-to is not strictly respected either. Several of us sending email as petsc-maint mixes up a lot of address books and Gmail will not allow me to send mail that way because Matt already claimed it and Gmail won't let two users send via the same address. No such problem from pine [even though most of you think its an antique tool for current times] The problem is server-side. I use Notmuch for most list mail (excluding messages sent from my phone) so I can write whatever headers I want, but smtp.gmail.com insists on only sending mail from verified addresses. This is to limit outgoing spam and spoofed message headers. The logic they have implemented only allows one gmail account to claim a particular outgoing address. Any smtp server should be fine. [but I guess if one doesn't work - all won't work]. I usually tunnel imap/smtp over ssh [eventhough is not required for smtp]. But you do go to places with blocked ssh - so that doesn't help. If I send it via a private host, it's hard to avoid being (occasionally) blocked as spam, especially when the server does not match the email address. Sending via Argonne's server fixes that problem, but then I have to be able to access their server to send email. But this is drifting off-topic. The question is whether it's better to munge Reply-to for petsc-users and petsc-dev, which boils down to: Is it feasible to adopt mailing list etiquette of using reply-all or must we stick with the current mode of munging Reply-to? The former has many benefits, including making more email discussion searchable.
[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 - 3.3-p6?)
On Wed, 17 Apr 2013, Jed Brown wrote: But this is drifting off-topic. The question is whether it's better to munge Reply-to for petsc-users and petsc-dev, which boils down to: Is it feasible to adopt mailing list etiquette of using reply-all or must we stick with the current mode of munging Reply-to? The former has many benefits, including making more email discussion searchable. This benefit is a bit dubious - as you'll get some migration of petsc-maint traffic to petsc-users - but then you loose all the 'reply-to-individual' emails from the archives [yeah - reply-to-reply emails with cc:list added get archived - perhaps with broken threads]. For myself - I can fixup my client side config for mailing lists to be similar to petsc-maint. So this change is up to you and Barry - who deal with these personal e-mails [which I guess you are already used to - and are ok with] And then there is spam - which you say can be dealt with filters. Is this client side or server side? Side note: if its client side - then I would expect users could be doing the same for current mode - and not have to do the 'subscribe' but set config to 'not recieve e-mails' stuff. satish
[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 - 3.3-p6?)
Satish Balay balay at mcs.anl.gov writes: This benefit is a bit dubious - as you'll get some migration of petsc-maint traffic to petsc-users - but then you loose all the 'reply-to-individual' emails from the archives [yeah - reply-to-reply emails with cc:list added get archived - perhaps with broken threads]. Thus the canned response: Please resend your last message with all Cc's intact so that I can reply to it on the list. Having a consistent convention between petsc-users/petsc-dev and petsc-maint would be fine by me [1]. And then there is spam - which you say can be dealt with filters. Is this client side or server side? Preserving unmunged headers makes existing spam filters more accurate. For example, petsc-maint is considered to be an important address in my mails, making it less likely to label mail setting Reply-to: petsc-maint as spam. This is one of many criteria and I don't know how significant it is, but anecdotally, petsc-maint spam is almost never detected by gmail's spam filter, while git at vger.kernel.org spam is usually detected. And header munging could be turned off without enabling anonymous posting. Maybe we can provide a one-click subscribe-without-delivery? [1] petsc-maint could become a mailing list with private delivery, but anonymous posting, fixing minor annoyances like RT delivering mails a second time to original recipients, and setting Message-ID matching In-Reply-To.
[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 - 3.3-p6?)
On Wed, 17 Apr 2013, Jed Brown wrote: Satish Balay balay at mcs.anl.gov writes: This benefit is a bit dubious - as you'll get some migration of petsc-maint traffic to petsc-users - but then you loose all the 'reply-to-individual' emails from the archives [yeah - reply-to-reply emails with cc:list added get archived - perhaps with broken threads]. Thus the canned response: Please resend your last message with all Cc's intact so that I can reply to it on the list. Having a consistent convention between petsc-users/petsc-dev and petsc-maint would be fine by me [1]. And then there is spam - which you say can be dealt with filters. Is this client side or server side? Preserving unmunged headers makes existing spam filters more accurate. For example, petsc-maint is considered to be an important address in my mails, making it less likely to label mail setting Reply-to: petsc-maint as spam. This is one of many criteria and I don't know how significant it is, but anecdotally, petsc-maint spam is almost never detected by gmail's spam filter, while git at vger.kernel.org spam is usually detected. So it is a client side filtering. Curently there is no spam on the mailing lists - as it goes in for moderator approval. If we switch everyone will get spam - and users filters would have to take care of things. I guess gmail does it one way - but not everyone is on gmail. And then - if gmail spam fails because of Reply-to: petsc-maint - then thats a useless spam filter. RT doesn't have to set that field. Any spamer can do that trivially. And header munging could be turned off without enabling anonymous posting. yes thats possible. With that - we'll be trading off 'enabling users to subscribe-without-delivery' [who can easily use filters to prevent mailing list traffic flooding their mailbox] - at the cost of everyone remembering to 'reply-all' all the time. Maybe we can provide a one-click subscribe-without-delivery? I don't know. Will have to check with systems. For one - there are quiet a few posts to petsc-users without subscribing first. These mails go into moderation. I approve/subscribe the post so that they get the replies - and participate in the followup emails. I still don't see the benefits of changing the mailing lists [except for it being similar to git at vger.kernel.org, and sure - less time spent moderating]. The current situation isn't perfect. But changing appears to just switch one set of issues with others.. Satish [1] petsc-maint could become a mailing list with private delivery, but anonymous posting, fixing minor annoyances like RT delivering mails a second time to original recipients, and setting Message-ID matching In-Reply-To.
[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 - 3.3-p6?)
Satish Balay balay at mcs.anl.gov writes: So it is a client side filtering. Curently there is no spam on the mailing lists - as it goes in for moderator approval. If we switch everyone will get spam - and users filters would have to take care of things. I guess gmail does it one way - but not everyone is on gmail. Everyone with an email address gets sent spam so they must have some filtering mechanism in place. And no-subscription list traffic is not necessary; we could keep the current moderation system. And then - if gmail spam fails because of Reply-to: petsc-maint - then thats a useless spam filter. RT doesn't have to set that field. Any spamer can do that trivially. Yes, but they have to have done their homework to know that petsc-maint has some significance to me. If they did that much, they would always send me email spoofed to look like it came from you, Barry, and my girlfriend. And every spam message to the Git list would be Reply-to: Linus, etc. But that doesn't happen, and even And header munging could be turned off without enabling anonymous posting. yes thats possible. With that - we'll be trading off 'enabling users to subscribe-without-delivery' [who can easily use filters to prevent mailing list traffic flooding their mailbox] - at the cost of everyone remembering to 'reply-all' all the time. John Doe sends email to petsc-users and the mailing list rewrites Reply-To back to the list. Now any user hits reply-all and their mailer gives them a message that replies *only* to petsc-users, dropping the original author. This is a problem, and only a few mailers have a when From and Reply-To do not agree, assume this is mailing list munging and disregard the intent of the Reply-To field (RFC 2822) by also replying to the address found in From feature. In other words, any mailer that interprets the Reply-To field as its intended instead of semantics rather than in addition to will drop the original author, meaning lost replies for people that are not subscribed or have delivery disabled. Perhaps a middle ground would be to have the list copy the From header over to Reply-to (if it doesn't already exist) and then _add_ the list address to Reply-to. That still isn't quite right when cross-posting, but it would allow us to advertise subscribe with delivery off and ask questions on the list or even mail the list without subscribing instead of always write petsc-maint if you can't be bothered to filter the high-volume list.
