Document: FSC-0052 Version: 001 Date: 23-Sep-90 ZPTH ---- A proposal for making the PATH zone aware Gerard van der Land FidoNet 2:283/1.5 Status of this document: This FSC suggests a proposed protocol for the FidoNet(r) community, and requests discussion and suggestions for improvements. Distribution of this document is unlimited. Fido and FidoNet are registered marks of Tom Jennings and Fido Software. The PATH line can be a more accurate source of information than the SEEN-BY line to determine if a message is a duplicate. TosScan with Circular PATH Protection (CPP) enabled will consider messages that already have your address in them as duplicates. This works fine in conferences that are distributed within one zone, but in conferences spread across zones it can cause problems. Unlike SEEN-BY lines, PATH lines are not stripped at the zone gate, because they have a very important purpose: to be able to determine the used echomail topology and troubleshooting, like finding the cause of duplicate messages. Unfortunately this also means that if a message is entered at 1:283/1 and my boss would be running TosScan with CPP enabled, the message would be considered as a duplicate, because "283/1" is already in the PATH lines. If such messages are not deleted but stored in a duplicate directory, you will of course notice this happen and disable CPP, but you can't know if messages never reach your system because they were deleted for the same reason by another node that had CPP enabled. That's why I have the following proposal. If a message travels from one zone to another, the zone gateway should move all information in the current PATH lines to kludge lines with the following format: ^aZPTH: <origin zone>:<old path info> The receiving system in the destination zone creates a new PATH with his address in it. There is no need to support or allow 4D addresses in the ZPTH, since it is only supplements the existing PATH lines. Simple sample ------------- A message originating at 1:154/40 arrives at 1:260/340... ^aPATH: 154/40 970 9 157/200 265/7 13/13 260/340 ...and is sent to Europe. This is how I would see it: ^aZPTH: 1:154/40 970 9 157/200 265/7 13/13 260/340 ^aPATH: 310/11 507/1 512/0 280/0 283/1 Now suppose that 283/1 would gate it to zone 3, it would look like this when it gets there: ^aZPTH: 1:154/40 970 9 157/200 265/7 13/13 260/340 ^aZPTH: 2:310/11 507/1 512/0 280/0 283/1 The receiving node in zone 3 now creates a new PATH line with his address in it. Advantages ---------- 1) It enables Circular PATH Protection (CPP) on conferences that travel across zones without the risk of messages that are erroneous considered as duplicates and deleted. 2) A zone gate can optionally parse the ZPTH lines to see if his zone or the destination zone has already seen the message (CZP, Circular ZPATH Protection), which means a duplicate message will never go to another zone. Ofcourse this could only be used if it sure that messages shouldn't re-enter a zone. 3) You get a much better view on the used echomail topology, sometimes it is very hard to see where a message goes from one zone to another. 4) It will not screw up with any echomail processor as long as they ignore unknown kludges. Only nodes gating echomail from one zone to another would need to have a processor that supports the ZPTH kludge. 5) It will hardly increase the size of compressed mail archives.