Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
On Oct 15, 2019, at 8:07 AM, Peter da Silva wrote: > A mail server speaks SMTP for both inbound and outbound That’s only useful if you’ve configured Fossil to integrate with a third-party bidirectional SMTP server, which is *not* the only way to configure Fossil’s email integration: https://fossil-scm.org/home/doc/trunk/www/alerts.md#advanced Even if you did decide to tie your Fossil instance to a separate SMTP server for outbound email alerts, it’s a separate software integration for the inbound path, as I pointed out in my prior reply. Outbound requires writing an RFC 2822 message to a file or pipe, then calling “sendmail -ti” or similar on it. Inbound requires integrating with mbox, Maildir, DMBS storage, etc. You don’t get one for free by writing the other. Are you volunteering to write at least one of these inbound integrations? drh hasn’t decided to write any of them yet, and none of the other big Fossil contributors have decided they want to take such a project on, either. Someone needs to have the itch; who? Then with one of those written, we’ll want several more, because there’s half a dozen common alternatives to the way this can work. As I said in the prior reply, my impression is that drh simply isn’t interested in doing any of these, because he’d rather finish his own SMTP server, the partially-complete one currently built into Fossil. But his time isn’t infinite, so he’s apparently got better things to do than finishing it. Maybe he’ll eventually give up on that project and write one or more of these integrations with a third-party SMTP server. But that also has yet to eventuate. > IMAP/POP/webmail is all part of the user interface stack… That was just an illustration to show that the ability to send email via SMTP doesn’t mean you automatically get the ability to receive email via SMTP. Even when the same software is used for both communication directions, it’s a separate integration to do both tasks. In any case, a web forum is also part of the UI stack, so it is no surprise that Fossil Forums should also exhibit the sorts of asymmetries you find in other email-to-thingy systems. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
I think you're conflating things. A mail server speaks SMTP for both inbound and outbound, IMAP/POP/webmail is all part of the user interface stack... as would be the webforum component in any mailing list/web forum scheme. On Mon, 14 Oct 2019, 20:45 Warren Young, wrote: > On Oct 14, 2019, at 3:04 PM, Keith Medcalf wrote: > > > > On Monday, 14 October, 2019 14:18, Warren Young > wrote: > > > >> Fossil Forums allow you to subscribe to email notifications. From the > >> reader’s perspective, it’s really very little different from the current > >> Mailman based scheme. > > > > The preceding paragraph is completely at odds with the following > paragraph, and taken together, they are completely illogical and > inconsistent. > > You’re conflating inbound and outbound paths. The ability to send email > implies but does not require the ability to receive email. > > ...Which is why they’re often entirely different stacks, speaking > different protocols! E.g. SMTP outbound via Postfix, IMAP inbound via > Dovecot. > > > All it needs is to be able to "read and process" RFC-2822 formatted > message files that are found in an "inbound for me” directory > > That’s certainly one way that some email servers work. The most common > such scheme is called Maildir. > > But there’s probably at least half a dozen other ways it can work: mbox, > MySQL store, PostgreSQL store, whatever it is that MS Exchange does that’s > incompatible with the rest of the world… > > There are currently four supported outbound email setups in Fossil, and a > stub for a fifth: > > https://fossil-scm.org/home/doc/trunk/www/alerts.md#advanced > > Why would inbound be different? > > Fossil isn’t in a position where it can require a specific SMTP server. > It has to run on pretty much every common desktop and server platform. You > have to get pretty far down the long tail of OSes before you find one that > Fossil doesn’t get used on daily by someone. Therefore, we have to support > approximately everything. > > On top of integrating with all common SMTP stacks, drh long ago stated a > wish to write his own SMTP server. (The latter being why Fossil has the > start of one included!) This should not surprise you if you’ve followed > his career. :) > > The last time I counted up the pages of RFCs you have to implement to > speak to a large fraction of the Internet email infrastructure — which was > one of the times this argument came up on this mailing list! — it was > something like 500 pages of standardese. It is not just RFC-2822. Getting > to something useful will take time, which comes out of the time budget for > SQLite, Fossil, etc. > > There is the option of writing glue software between Fossil and whatever > SMTP infrastructure you already have, but no one’s bothered to do that in > the year or so that Fossil Forums have been in steady use. To me, that > speaks more of the desirability of inbound email submission than about its > inherent difficulty. > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
On Oct 14, 2019, at 3:04 PM, Keith Medcalf wrote: > > On Monday, 14 October, 2019 14:18, Warren Young wrote: > >> Fossil Forums allow you to subscribe to email notifications. From the >> reader’s perspective, it’s really very little different from the current >> Mailman based scheme. > > The preceding paragraph is completely at odds with the following paragraph, > and taken together, they are completely illogical and inconsistent. You’re conflating inbound and outbound paths. The ability to send email implies but does not require the ability to receive email. ...Which is why they’re often entirely different stacks, speaking different protocols! E.g. SMTP outbound via Postfix, IMAP inbound via Dovecot. > All it needs is to be able to "read and process" RFC-2822 formatted message > files that are found in an "inbound for me” directory That’s certainly one way that some email servers work. The most common such scheme is called Maildir. But there’s probably at least half a dozen other ways it can work: mbox, MySQL store, PostgreSQL store, whatever it is that MS Exchange does that’s incompatible with the rest of the world… There are currently four supported outbound email setups in Fossil, and a stub for a fifth: https://fossil-scm.org/home/doc/trunk/www/alerts.md#advanced Why would inbound be different? Fossil isn’t in a position where it can require a specific SMTP server. It has to run on pretty much every common desktop and server platform. You have to get pretty far down the long tail of OSes before you find one that Fossil doesn’t get used on daily by someone. Therefore, we have to support approximately everything. On top of integrating with all common SMTP stacks, drh long ago stated a wish to write his own SMTP server. (The latter being why Fossil has the start of one included!) This should not surprise you if you’ve followed his career. :) The last time I counted up the pages of RFCs you have to implement to speak to a large fraction of the Internet email infrastructure — which was one of the times this argument came up on this mailing list! — it was something like 500 pages of standardese. It is not just RFC-2822. Getting to something useful will take time, which comes out of the time budget for SQLite, Fossil, etc. There is the option of writing glue software between Fossil and whatever SMTP infrastructure you already have, but no one’s bothered to do that in the year or so that Fossil Forums have been in steady use. To me, that speaks more of the desirability of inbound email submission than about its inherent difficulty. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
On Monday, 14 October, 2019 14:18, Warren Young wrote: >Fossil Forums allow you to subscribe to email notifications. From the >reader’s perspective, it’s really very little different from the current >Mailman based scheme. The preceding paragraph is completely at odds with the following paragraph, and taken together, they are completely illogical and inconsistent. >What Fossil Forums currently does *not* allow is posting or replying via >email. That requires either tight integration with some other SMTP mail >server so that incoming mail can be delivered to the Forum feature for >email address vetting and such, or it requires that Fossil itself has an >SMTP email server built in so it can handle it directly. All it needs is to be able to "read and process" RFC-2822 formatted message files that are found in an "inbound for me" directory, and write RFC-2822 formatted message files into an "outbound from me" directory. There is really nothing inherently difficult about that. What it does is simply read files from the inbound directory and write messages to send to the outbound directory. If it can do these things it can interact with every MTA in existence. This is how e-mail message processors work, and what almost all mailing list processors do (though some are integrated differently because being generic and Keeping It Simple Stupid is apparently not a thing). And yes, there is no reason that the part betwixt reading the inbound and writing the outbound cannot create a "Web Forum" for those so inclined. I think if you go back a couple of dozen years these sort of "gateways" were all the rage. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
On Oct 11, 2019, at 11:33 AM, Tim Streater wrote: > > A mailing list suits me just fine. It works well and gets next to no spam. In > addition, it's not yet another damn website I have to log into to use and > remember my username/password for. And I don't care if it's not "modern”. Fossil Forums allow you to subscribe to email notifications. From the reader’s perspective, it’s really very little different from the current Mailman based scheme. What Fossil Forums currently does *not* allow is posting or replying via email. That requires either tight integration with some other SMTP mail server so that incoming mail can be delivered to the Forum feature for email address vetting and such, or it requires that Fossil itself has an SMTP email server built in so it can handle it directly. There’s a start to both options in the current code base, but neither method is anywhere near production-ready. That may be one reason why this mailing list isn’t a Fossil Forum yet. We get a bunch of benefits in exchange for this loss of functionality relative to traditional mailing lists, given at the top of this doc: https://fossil-scm.org/home/doc/trunk/www/forum.wiki I’m a bit of a mailing list traditionalist myself, but I’m also quite happy with the way the Fossil Forum feature came out. I’m using it myself on my own public projects. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
On Oct 11, 2019, at 9:56 AM, Brannon King wrote: > > I'd like to propose that we > upgrade to something more modern and secure like Sympa or mlmmj, or even a > more drastic system upgrade to something like Redmine -- a project > tracker + forum. This is a really old argument, which we’ve had at least twice before. You can dig those old threads up in the archives. (Ha!) drh created Fossil Forums as his answer to the debate. The only question is how long it will take for him to decide to move the SQLite mailing lists to a Fossil Forum, not whether we’ll move to Redmine instead, or whatever. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
On Oct 11, 2019, at 9:41 AM, Mike Bayer wrote: > > what is the reason that the SQLite mailing list archives...are private for > members only in order to be read? Probably because you can extract email addresses and real names from the archives. Harvesting of such information is a problem inherent in any SMTP mailing list that wants to allow direct replies to individual members without going back through a central service, as Mailman allows. That gives three alternatives: 1. Let any bad actor harvest this info. 2. Hide the info entirely so that direct replies aren’t possible. 3. Switch to some other tech that ensures that only list members can talk directly to other list members, so that the up-front anti-spammer tech prevents the service from being used for spamming. The first two are probably options in Mailman, but they aren’t great options. > The archives can be viewed at a mirror such as > http://sqlite.1065341.n5.nabble.com/ Those mirrors usually take option #2 above. If this mailing list moves to any other service, it is likely to be to a Fossil Forum, which we’ve been using successfully within the Fossil project — a DVCS created to aid the development of SQLite — for about a year now. You can read more about this feature here: https://fossil-scm.org/home/doc/trunk/www/forum.wiki and you can see the existing forum here: https://fossil-scm.org/forum/forum That’s not for SQLite discussion. I’m pointing you to it so you can see what this mailing list may eventually become. Fossil Forums currently implement option #2 above, but I’m hoping we get #3 eventually. > Additionally, it appears that the SQLite Mailman server is configured to > suppress "reply-to" to the sender of an email. You can’t get everyone on the list to agree with The One True Way such settings must be set, so *someone* will always be unhappy with the way the list works. > making the mailing list opaque leads to user questions that are entirely > related to SQLite and nothing else being posted in downstream project > communities instead, which pushes the community response burden downwards. You’re ignoring spammers, other bad actors, GDPR… Complete transparency simply isn’t possible any more in 2019. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
Brannon King wrote: > [...] I'd like to propose that we upgrade to something more modern and > secure like Sympa or mlmmj, or even a more drastic system upgrade to > something like Redmine -- a project tracker + forum. I would propose instead to upgrade to a NNTP. (I even wrote a NNTP software that is using SQLite, and is in the public domain.) And for project tracking, I think there is Fossil for that, isn't it? ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
> On Oct 11, 2019, at 9:19 AM, Mike Bayer wrote: > > GNU Mailman is still very widely used and IMO does the job very well Its web interface is like something from 1997. In particular, it makes reading archives very painful, clicking through to one message at a time. I’d recommend groups.io — it hosts mailing lists with excellent browsable archives, or from another perspective, web forums with excellent email notifications. In my experience it pleases both mailing-list and forum fans. —Jens ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
On 11 Oct 2019, at 16:56, Brannon King wrote: > I agree that Mailman is archaic. I worry about the security on it. I don't > enjoy using 3rd-party mirrors for searching it. I'd like to propose that we > upgrade to something more modern and secure like Sympa or mlmmj, or even a > more drastic system upgrade to something like Redmine -- a project > tracker + forum. A mailing list suits me just fine. It works well and gets next to no spam. In addition, it's not yet another damn website I have to log into to use and remember my username/password for. And I don't care if it's not "modern". -- Cheers -- Tim ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
Are there specific Mailman CVEs you can refer towards such that these settings could not be opened up? The read-only archives appear to be static files, so there is no additional security issue that isn't already presented by the existing cgi-bin already open for public access. Similarly for the reply-to issue, only email addresses present in messages that have been approved to be part of the list would be subject to an automatic reply. As a project maintainer myself, I wouldn't want to link these simple improvements to a wholesale replacement of the mailing list system. GNU Mailman is still very widely used and IMO does the job very well, and if the archives were opened up then they would be indexable by search engines such as Google. On Fri, Oct 11, 2019, at 11:56 AM, Brannon King wrote: > I agree that Mailman is archaic. I worry about the security on it. I don't > enjoy using 3rd-party mirrors for searching it. I'd like to propose that we > upgrade to something more modern and secure like Sympa or mlmmj, or even a > more drastic system upgrade to something like Redmine -- a project > tracker + forum. > > On Fri, Oct 11, 2019 at 9:41 AM Mike Bayer wrote: > > > ...I would ask them to consider that making the mailing list opaque leads > > to user questions that are entirely related to SQLite and nothing else > > being posted in downstream project communities instead, which pushes the > > community response burden downwards. > > > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] rationale for private archives of the SQLite mailing list and suppressed reply-to
I agree that Mailman is archaic. I worry about the security on it. I don't enjoy using 3rd-party mirrors for searching it. I'd like to propose that we upgrade to something more modern and secure like Sympa or mlmmj, or even a more drastic system upgrade to something like Redmine -- a project tracker + forum. On Fri, Oct 11, 2019 at 9:41 AM Mike Bayer wrote: > ...I would ask them to consider that making the mailing list opaque leads > to user questions that are entirely related to SQLite and nothing else > being posted in downstream project communities instead, which pushes the > community response burden downwards. > ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
