Re: [Pan-users] How would I debug Pan (intermittently) sending posts in triplicate?

[Duncan]

Rock posted on Wed, 10 Jul 2013 06:45:38 +0000 as excerpted:

> On Wed, 10 Jul 2013 06:38:50 +0000, Rock wrote:
> 
>> The result of those two actions, is a Message-ID generated by Pan of
>> the following address@hidden format:
>>   Message-ID:
>>   <pan.2013.07.09.15.44.22-LdB7NMw1lkWhjG8JX1ygEWCgeU
address@hidden>
> 
> Hmmmmm.... gmane obfuscated the FQDN so let me get around that with
> spaces:
>  
> Pan created a address@hidden of the format:
>   Message-ID: < pan.2013.07.09.15.44.22 AT domain.is.invalid >
> 
> After I performed the following two steps in Pan 0.135:

> 1. <flag name='add-message-id-header-when-posting' value='true'/>

> 2. Pan:Edit->Edit Posting Profiles->Message-ID Domain
> Name->domain.is.invalid
> 
> QUESTION:
>  What is different in the latest Pan for the same result?

Hmmmm indeed. Let me first add a caveat to what I said previously:

I don't see anything in pan's /GUI/ that give me the option to not set 
message-id any longer.  I *DO* still see the add-message-id-header-when-
posting option in preferences.xml, but given that I've been updating the 
same preferences.xml file for years and seldom actually change
preferences[1], it's quite possible that option is stale and no longer 
used or written to /new/ preferences.xml files.

So while there's still an option for it in preferences.xml, there's 
nothing I can see in the GUI about it, and for all I know the 
preferences.xml line for it is stale and now does nothing at all.


Meanwhile, you mentioned gmane; I'm actually using pan to post to this 
list via gmane, so you can check my headers to see what pan's doing now. 
=:^)

As you'll note, pan now includes the full version including the git 
commit (for those building pan from git as I do) in the user-agent 
header.  (FWIW it also includes the upstream cloned-from git repo, which 
in my case given that I'm using the gentoo ebuild means I'm leaking the 
local machine path to the bare-clone that the ebuild updates and then 
reclones from each time I build, which I'm not too happy about, but I've 
obviously not been unhappy /enough/ about it to boost the priority of 
patching that bit out in ordered to stop that local information leak...)

And as you can see, the message-id generation algorithm has changed 
substantially as well.  It's no longer just the date and time with a 
hopefully unique domain name appended, but a string that starts with pan 
and at least appears to be much more likely to be random (I've not 
actually looked at the sources to see what it's actually generated from, 
but it /appears/ more random, certainly), which combined with the 
selectable domain name, should minimize any chance at message-id 
collisions.

FWIW in my case I've not set anything for the domain name, so pan is 
using its defaults for that, which would appear to derive from the domain 
name of the email address set in the posting profile, with the customized 
domain name setting as you noted in the posting profile as well.

I'd guess the code for the domain name bit hasn't changed, however, so if 
you don't set anything there (as based on your headers seems to be likely 
for your gmane posting profile), it should simply take the domain from 
your email address.

Which means if you use an invalid email address for newsgroup posting 
(assuming you can thru aioe, obviously you can't for gmane), you can 
simply set the domain used there as appropriate, and avoid setting the 
custom message-id domain if you like.

But your older version of pan does still have the less likely to be 
unique message-id algorithm code, so whether default-deriving from your 
email address domain name or custom-setting one specific to the message-
id, using something definitely less common than the "gmail.com" domain 
you're apparently currently using for your gmane posting profile, should 
help increase the likelihood of the full message-id string being unique.  
So even something like asoi7840-1894.sample.com (the first bit just being 
a mashing of a bunch of keys, then deleting semicolons and etc that for 
all I know are illegal in both domain names and message-ids) as custom 
domain name should be useful, and way less likely to generate collisions 
than say gmail.com.

And sample.com is a reserved domain name used in the RFCs, etc, so 
appending that at the end should safely avoid any chance of collision 
with a real domain...

OTOH, those interested in maintaining at least some illusion of 
pseudonymity will probably want to use a more common domain name (such as 
gmail.com) and take their chances on message-id collisions.  Of course in 
that case there's a lot of other info leakage in the typical headers 
they'd need to worry about as well, but pan's open source and can easily 
be patched to omit or change stuff like the user-agent string if desired, 
and posting thru an anon-remailer to either an open for posting news 
server or one to which one has subscribed with say a mail order purchased 
with cash in and mailed from a foreign city (and to which one never 
directly connects), could help with that.

---
[1] preferences.xml updates: As it happens there's some sort of 
apparently GTK-rooted GUI bug that seems related to a load-time race 
condition that sometimes zeros out column widths in the header pane.  For 
some time I was having to jump thru hoops every time the columns 
(apparently randomly) zeroed out to get them to display properly again, 
but eventually I got tired of that and now have a set of patches that get 
conditionally applied by a script at every pan startup, one for each 
column.  If that particular column width values is zeroed out, the patch 
resets it to the desired value.  Thus, when I see the problem occur I can 
simply quit and restart pan, applying the patches via my pan startup 
script, and get a working header pane layout once again without too much 
hassle.  Of course that resets the file modification time, as does the 
triggering bug I'd guess, so I can't simply use the mod-time to see the 
last time I actually did a deliberate preferences change, as I normally 
would.

-- 
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