Text 14318, 80 rader
Skriven 2014-04-10 15:09:18 av Kees van Eeten (2:280/5003.4)
  Kommentar till text 14310 av Björn Felten (2:203/2)
Ärende: Seen-by stripping
=========================
Hello Björn!

10 Apr 14 14:15, you wrote to Wilfred van Velzen:

 BF>    Sounds like a great feature -- the foresight to even think of such a
 BF> feature is really impressive. Kudos to that developer.

 That is not forsight, but adaption to current needs. Wilfred is the maintainer
 of the software, but I agree, it is nice that he added the option, to trace
 thye source of your problem.

 WvV>> I've also searched my message base for them (= did a grep on 'INTL '
 WvV>> in the *.jhr files of my jam areas). And found a couple just like
 WvV>> Kees did, but only quite old ones:

 BF>    I know. Just like Kees too, I've got the same result. Most likely
 BF> because at least one of the two tossers, first SquishMail and then
 BF> CrashMail, all messages have to pass before getting to my jam areas,
 BF> strips out erroneous kludges.

 I am quite shure that my tosser does not remove the INTL kludge. I generate
 12 monthly an one yearly statistics report in a certain echo. The INTL is
 there, because I use a utillity for converting text files to netmail.
 By adding the area tag, it is distibuted as echomail, but the INTL
 kludge is there.

 I have a database with messages, where some are as old as from 1996. Searching
 for particulars is not difficult, nor time consuming, as all is based on
 Mysql. As I have written before, I only found old gated newsgroups and
 my statistics messages with the INTL kludge.

 Not to long ago somebody said, leave echo mail distribution to those who
 know what they are doing. Those who have done so in the past were at key
 positions in the distribution. When something went wrong, their mental state
 technical abillities, structure of their intestines and gymnastic abillities
 would be questioned. In other words they learned the hard way.

 Many others were just leafnodes and the configuration of their systems was/is
 not as critical, as all happens within one zone and often one region.

 Now with costlimits removed, everybody want to become free of the old
 "echomail baron" structure and connects every where and across zones.

 You are now surprised, that when all kind of leaf nodes are becoming
 distribution points, that anomalies surface.

 In many cases, 1:261/38 will be in the path for the simple reason, that
 apparently everybody wants to connect to the Mother(node) of Fidonet.
 Be it as an out of zone node, or point system. It is not 1:261/38 that
 causes the "problems", those were ironed out a long time ago, as I mentioned
 above.

 With this new generationd of echo movers, I do not mean you, you have been
 doing so for a long time, but you do encourage a generation og leafnodes
 to connect everywhere, so work with them to solve the problems they cause.

 If it apears that you may need assistance from the old structure, don't
 blame them for the problem first. Those allegations are unfunded and do not
 lead to a cooperative atmosphere.

 BF>    That's why I hoped for some interference *before* the tossers have
 BF> a go at it.

 Put a copy aside before the tosser starts. Dissecting a pkt file is no
 rocket science. If you are loking for text outside the header, you can just
 load them in a text vieuwer, if you can tell the viewer to ignore that
 it is a text file. There are plente of snippets of perl code on the net,
 that can give you a hint how to dissect a pkt file, I have also done it in
 php without problems.

 And do read the hint that Wilfred gave, thet many of the new participants in
 echo distribution, may be running older software, that still does old style
 zone gating within fidonet.

 Just my 5 cents.

Kees

--- FPD v2.9.040207  GoldED+/LNX 1.1.5
 * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)