I think that what needs to be done is for each foo at sqlite.org to return an error/undeliverable message if someone sends a message to it, citing that all messages must be explicitly sent to the corresponding foo at mailinglists.sqlite.org. That should handily solve the problem. -- Darren Duncan
On 2015-03-02 10:37 AM, Mike Owens wrote: > For what it is worth, the move to mailinglists.sqlite.org is a result of > the Mailman web interface having to be hosted under the following two > constraints: > > 1. It must be on port 80 > 2. It cannot be on sqlite.org port 80 > > I explained this reasoning in a previous email. The short version is > because we are using two web servers on the VM that hosts both the > sqlite.org website and fossil repos (althttpd) and the Mailman web > interface (Apache). We previously did this on a single IP where mailman was > on port 8080. However, we had a significant number of complaints from > people who could not reach the Mailman web interface via sqlite.org:8080 > due to firewall restrictions in their respective locations. So we did what > we could to move it to port 80. > > So to satisfy these two constraints, mailinglists.sqlite.org was born. > Unless somebody else knows better, Mailman does not allow one to use two > domains for a given list. Either something will screw up with the mail > routing or in the web interface if you try to use more than one. You have > to pick one domain and stick with it. Thus I could not continue to support > both the previous sqlite.org (:8080) domain and the new > mailinglists.sqlite.org (:80) for the users list. So I made the move from > the one to the other. > > Regarding the reply-to policy. I honestly don't remember the reasoning > behind it. I know there was a big long discussion about it in the past > (search the list) and after the dust settled we chose the current policy > and that is the way it is configured today. I do believe the policy was a > result of the consensus of the mailing list users. I can say that we do > everything we can to make most of the people happy most of the time. That > is the very reason we made this change to begin with -- to make it possible > for everyone to use the list. It would have been easier to just keep things > the same and let the people who can't reach port 8080 deal with it, but we > did what we had to to make it accessible for them as well. There are a lot > of variables in the system and we juggle them as best we can. > > Any feedback or suggestions are always welcome. > > > On Mon, Mar 2, 2015 at 5:18 AM, David Woodhouse <dwmw2 at infradead.org> > wrote: > >> On Mon, 2015-03-02 at 12:45 +0200, R.Smith wrote: >>> Ok, I've found the source of the list duplications. >>> >>> Some emails (Such as the one by J.K. Lowden 2-March-2015 re: Characters >>> corrupt after importing...) contains a "Reply-To" field in the header >>> with both list addresses which must have sneaked in there due to some >>> automatic list feature. (By "Both" I mean the old: >>> sqlite-users at sqlite.org and the new: >> sqlite-users at mailinglists.sqlite.org) >> >> You don't need that, do you? Just hitting Reply All to a message which >> is: >> To: sqlite-users at sqlite.org >> Reply-To: sqlite-users at mailinglists.sqlite.org >> >> would generate a message which ends up going to both, wouldn't it? >> >> (I can't easily test; I've configured my mailer to ignore abusive >> Reply-To: headers from mailing lists where it can detect them, so my >> Reply and Reply All buttons actually do what I *ask* them to.) >> >> But looking at the first message in the 'PhD Student' thread, it appears >> just as in my example above. And John KcKown's response of 26 Feb 2015 >> 07:16:47 -0600 is indeed to both addresses, as if he'd done the correct >> thing and simply hit 'Reply All'. >> >>> I usually use the "Reply to List" button (Thunderbird) which replies >>> correctly, >> >> Note that that is considered extremely anti-social in many cases, >> because it cuts some people out of discussions entirely. See >> http://david.woodhou.se/reply-to-list.html for a full discussion. >> >> -- >> dwmw2
