Re: [Pan-users] posting via gmane??

[Duncan]

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