On Tue, 09 Jul 2013 13:54:16 +, Duncan wrote:
> Of course if pan's not setting the message-ids but instead letting the
> server do it, both it and the server have far less to go on when they try
> to pick up the pieces from the lost connection.
Hi Duncan,
Thank you for that excellent and
On Wed, 10 Jul 2013 06:38:50 +, Rock wrote:
> The result of those two actions, is a Message-ID generated by Pan
> of the following pan.date.time@FQDN format:
> Message-ID:
Hm gmane obfuscated the FQDN so let me get around that with spaces:
Pan created a pan.date.time@FQDN of the
On Tue, 09 Jul 2013 13:54:16 +, Duncan wrote:
> It's worth noting here that in current pan, the option to let the server
> assign message-id is gone. Pan always assigns a message-id now, but does
> have an option to let you set the domain used in the message-id if you
> like. Perhaps this
On Tue, 09 Jul 2013 13:54:16 +, Duncan wrote:
> you can use the "ngrep" tool (homepage http://ngrep/
> sourceforge.net , if you'd like to read a bit about it before
> installing...)
Hi Duncan,
Thanks for that advice.
I installed ngrep and am working on understanding how to use it to
debug
Rock posted on Tue, 09 Jul 2013 05:11:42 + as excerpted:
> Have you ever seen this problem (and do you have insight into the
> cause)?
>
> I'm using Pan 0.135, which is the latest easily possible on Centos6
> (long story)
> and, at times, but only with aioe.org:119, I end up with triplicate
>
