Beartooth posted on Wed, 24 Sep 2014 18:35:52 +0000 as excerpted: > Like others here, I subscribe to lists and set them immediately to > nomail, because I try never to look at one in email if I can get it via > Gmane. (I also happen to hate webmail with the purplest of passions, > btw; I know some form of it exists with a Gmane connection, and I have > to forgive Lars for that, but wild horses that try to drag me there will > become instant horsemeat.)
AFAIK, gmane has a web interface to its archive, that has a reply option as well, but I wouldn't link that with webmail. I'd consider it more what I just said, a web interface to an archive, that happens to be of mailing lists, but I doubt anyone familiar with gmane would argue that it encourages or emphasizes the /email/ aspect of that at all; rather to the contrary, it provides both a web interface and a news interface as /alternatives/ to the normal email interface to mailing lists. Of course I'm assuming you don't have information about some gmane- related webmail project of which I'm unaware... > Pan/Gmane is great for *reading* lists gatewayed from email; but > I get mixed results with *postings* and attempts to post. Sometimes they > go through. Sometimes I get an automated note from Gmane, requiring me > to prove my humanity by replying, and then they go through. And > sometimes they seem just to fall into some vast empty cyberspace. > > Is this a Pan matter, or a Gmane matter, or something I have to > take up with listowners? (I favor the last, because Istr getting across > some listowner who couldn't be bothered, once long ago and far away.) I believe you're conflating two and possibly three different issues, tho you're certainly not alone in your confusion as I've seen others confused over the exact same thing. Viewed from a high level, without the minutia of detail, the first thing to realize about gmane replies is that gmane simply acts as a relay -- basically, it converts your news reply back into email and sends it to the list-serv as if it was simply an email relay, thus gating the reply back to mail, reversing the process of gating the mail it gets from the lists to news. Once it hands off to the list-serv, gmane's reply relay job is done and it's up to the list-serv to process the mail using list- serv rules. Assuming the list-serve mails out the message, gmane treats the message just like any other once it receives it as a message from the list. At that point, it's just another message from the list and gmane doesn't care that the message was actually relayed thru gmane before it hit the list-serv. This reply-relay by definition adds an additional hop to the chain that the message has to pass in ordered to get sent out on the list, and that additional hop by definition must increase the complexity and fragility of the process as a whole, as opposed to simply sending the mail directly. That bit is only gmane's fault to the extent that it provides the service at all, as there's no way to provide that service /without/ adding that extra hop and consequent additional places for something to go wrong. Once you have that concept in mind, it's easier to understand the details. The second thing to keep in mind, still high level but down the level scale slightly from the above, tho the discussion below gets a bit detailed, is that while a message sent directly to a mailing list has one level of authentication to go thru, a message sent via gmane has two. If either one fails, the message doesn't get posted, to the list or to gmane, since the only way messages get posted to gmane is if they are received from the list-serv via gmane's subscription. Gmane level authentication is the first one and is one-time (assuming you reply, authenticating yourself) per list/group. Once you reply to the gmane authentication prompt for that group/list, gmane will automatically forward all future replies from you via gmane to that list[1]. The idea here is to ensure that users are using real email addresses that they can actually receive mail on, and also that they actually intend to post to that list (see the next paragraphs). Technically, gmane wouldn't /have/ to do this, but it's in the interest of all gmane users that it does, since it cuts down on spammers via gmane quite a bit as they have to reply to at least one message on the address they use, and without that, most list admins would surely blacklist gmane replies entirely. So while it's a small hassle, it's also critical to being able to use gmane for replies /at/ /all/. One possible source of confusion here is on cross-posted messages. Keeping in mind that the list2news correspondence and gating isn't perfect, if gmane receives a cross-posted message it will attempt to forward it to all the corresponding lists. But what happens if you're a regular on one such list and have thus long ago replied to the gmane authentication challenge for that list, but have never confirmed to gmane that you want to send messages to the other list(s) in the cross-post? As might be predicted, you get the gmane email asking if you want to post to the list you've not yet confirmed. However, gmane forwards your mail to the one you're a regular on right away, as you long ago confirmed it. But this is something the gmane confirmation email doesn't make quite clear, because it was designed with single-list posts in mind, not cross- posting. Thus the confusion. Making this case a bit worse for pan users is the fact that pan doesn't challenge cross-posts unless you're posting to more than I think three lists (or five? IDR) at once. It does list the other groups in the newsgroups line in the posting dialog, but if you're like me, most of the time you don't notice that and only realize the message was crossposted if you get that email from gmane asking for confirmation to post to a list you didn't even know you were posting to in the first place, because you didn't notice the newsgroups line. Side note: I really wish this was a pan option. I want pan to warn loudly for ANY cross-posting, tho it should allow me to go ahead and do it anyway if it's not TOO many lists. What I've taken to doing here in most cases is simply ignoring the gmane confirmation emails for lists I didn't intend to post the reply to in the first place. I have no reason to want my replies on some ubuntu or fedora list, just because someone decided to crosspost the original message to it as well as to the pan or kde or whatever list I saw the message on and replied from, so I just let the gmane confirmations that would allow me to post to that list timeout, and my replies presumably never see that list as a result. The second level of authentication is that of the list-serv itself. Gmane has nothing at all to do with this; gmane simply forwards the message, and the list-serv does with it whatever the list-serv is configured to do, which in many cases is to confirm posts from non-subscribers (open list with confirmation), but it can also simply refuse them (closed list, must be a subscriber to post, period), or send them to a human moderator to confirm (moderated open list, non-subscriber posts may be delayed in the moderator queue for some time but if on topic should eventually show up), or post them automatically (fully open list, no confirmation, not common due to spam, but still seen on lists such as those hosted by vger.kernel.org, which has other strong anti-spam measures including HTML and unrecognized binary-attachment type filters). Again, unless the list-serv has a rule blacklisting posts relayed thru gmane (up to the admin, some do, I guess), the processing here is exactly the same whether you post directly to the list via email, or whether you post thru gmane. If you make sure you're a list subscriber (with the same address as you use on gmane, obviously important, but something easy to lose track of if you have multiple email addresses) and set nomail mode, as you mentioned above, in theory, the list-serv authentication level won't be a problem, since you're a subscriber and the rules for non-subscribers shouldn't apply at all. The single exception is if the list-serv blacklists gmane relayed posts even for subscribers. Regardless, at this level it's 100% the list-serv admin's policy at play, out of gmane's control entirely[2]. But there remains some confusion here, due to the *TWO* levels of authentication when replying thru gmane, the gmane human-verification level, and the list's own level, entirely out of gmane's control. If people don't realize that and conflate the two, it becomes very confusing indeed. Then once gmane forwards the message and the list-serv posts it, gmane gets it as it it would any other message from that list and like any other subscriber to that list would get it. Occasionally, a message will (apparently) be posted to the list and I'll see the replies to it, but the message itself either never appears on gmane, or gets posted on gmane later, after the replies to it have already appeared! There isn't much that can be done about that. It's simply the reliability of the email system and of the gmane processing of it, at this stage. Hardware does break; software does have bugs. Live does go on, just as it would if you had subscribed to the list directly and you ended up seeing replies to a message before the message itself came in. That too happens occasionally so it's not just gmane, altho admittedly the gmane list2news gating process adds additional complexity and more software and hardware that can break. > And do my drafts automatically get preserved somewhere? Istr also that > at one time they didn't, alas! Yes, messages in-progress do get auto-saved now, as do sent messages. In the compose window, if you hit the open-draft button (or use the open- draft file-menu function or hit the corresponding hotkey), you should see an "autosave" file, the /autosave/ of the current message in progress. If you use the save-draft function, you can of course save to that file manually, or to another filename, if you like, which will then allow you to load it from open-draft as well. However, due to the way autosave works and the fact that you only get the open draft option once you're composing a message, which by that point has already overwritten the previous autosave, if you want to retrieve a message you were composing at the time of a crash, you have to do a little file-rename dance to get to the previous autosave before it's overwritten by a new one when the compose window is opened in ordered to get to the open draft functionality. Since many of my replies are long and involved, sometimes taking hours to write as I check references and write and rewrite paragraphs until I'm happy enough with things to hit send, I have a bit of experience with retrieving half-written posts from drafts. =:^\ Here's what I do. Before opening pan's compose window after a crash, I browse to the drafts directory under the pan home dir (so ~/.pan2/article-drafts , by default). Once there, I find the autosave file and rename it to something else, generally reflecting whatever topic I was discussing at the time. Then in ordered to open the compose window I act as if I was going to compose a new message, only once the compose window is open, I can select open draft, and instead of opening the autosave (which will at this point be the new, now blank, message), I can select and open the renamed file instead, thus retrieving my half-written message and hopefully allowing me to finish and send without further crashes. As for sent messages, that functionality is there but still a bit buggy. There's a sent-messages folder (pseudo-group) under local folders. This is where you'll find your sent messages. However, while messages sent during a particular pan session do appear here, they don't appear as cached until the next session. And since there's no real newsgroup corresponding to this pseudo-group, attempting to read the message won't cache it, since there's not a real server to download it from. So to actually view the full message, you first have to quit and restart pan, which will cause it to check which messages are cached and thus display the messages from the last session as now cached. You can then read them as you normally would. The other quirk with sent messages is that since it's a pseudo-group not attached to a real news server, the usual method pan uses to track which messages are read and which are unread, fails. Every time pan restarts, all messages in the sent folder again appear as unread. You can read messages in sent and they'll show as read for that session, but because pan has no way to save that information, once you restart pan, all messages in the sent folder again appear as unread. Tho viewed in another way, this bug could be considered a feature, since unless you've read sent messages in a particular session and assuming you haven't deleted any of them, you effectively have a running count of the number of messages you've posted since pan started using the sent- messages folder. =:^) --- [1] Assuming that group/list isn't marked as one-way, like many announce groups are. Pan's announce list for example, is normally only used to announce new pan versions, and only a couple pan devs (Petr Kovar, and possibly KHaley and Heinrich Mueller) have access to post to it. I'm not sure it's on gmane as I want direct email from it and have thus subscribed directly, but if it is, it'd be marked one-way, since ordinary users aren't /supposed/ to be able to post to it. [2] Well, if gmane were to kill its authentication level, as pointed out above, most list-admins would likely blacklist gmane entirely, so gmane can and does do something to prevent that and help admins to look favorably on it, but a list policy is a list policy, out of the control of gmane other than the fact that gmane tries to avoid being blacklisted as an abused relay. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
