Hello Alan!

25 Apr 21, Alan Ianson wrote to Kai Richter:

 AI> Mail arrives in my inbound as it is prepared by other nodes. This is
 AI> not a configuration or choice on my part.

Let's say yes, true. I don't want to switch to bastard operator from hell mode. That path would end in destruction.

 AI> I always send netmail uncompressed for both secure and insecure
 AI> sessions.

 AI> Perhaps we need a standard of some sort but there is none that I know
 AI> of.

If you are really interested i'd like to recommend the fidonet policy. This is Fidonets initial document. It's latest approved version is 4.07 of 1989. Some things may be outdated today but the basics are still displayed.

You asked for this part:

"2.1.8  Exclusivity of Zone Mail Hour

Zone Mail Hour is the heart of FidoNet, as this is when network mail is
passed between systems.  Any system which wishes to be a part of FidoNet must
be able to receive mail during this time using the protocol defined in the
current FidoNet Technical Standards Committee publication (FTS-0001 at this
writing).  It is permissible to have greater capability (for example, to
support additional protocols or extended mail hours), but the minimum
requirement is FTS-0001 capability during this one hour of the day.

This time is exclusively reserved for netmail."

FTS-0001 is on revision 16 of 1995 and is the definition of the *.pkt format. A packet is a bundle of messages that is stored in the type 2 packet format.
(see line 462 and on)

Within the introduction text FTS-0001 is open for the future:

"2. Levels of Compliance

This  documents represents the  most basic FidoNet implementation. A future document will define well tested extensions which are optional but  provide sufficient  additional function that implementors  should seriously   consider them.   SEAdog(tm),  from  System   Enhancement Associates,  is  an  excellent example  of such an  extended  FidoNet implementation."

Today seadog is outdated in network operation but the minimum definition as most basic implementation for type 2 packets does still apply.

There are historical reasons why echomail handling with or without compression is not found in the policy. Based on the phone line cost structure in some/many/all?? countries of the USA a local area call was free of additional cost. This is why the host structure was implemented. There was one system responsible for long distance calls and so mass transportation was done by one system only. Local systems didn't need to think about costs and so compression was never required.

I'm not sure about how the echomail policy was build but this echopol shows how to handle compression:

"11.   ECHOMAIL SOFTWARE:   EchoMail  exchanges may consist of any
type of  archival storage  format agreed  upon by  both  parties."

This is the key element, any other archival format can be used if both sysops agree.

Well, to be honest, i'd like to stop here but the echopol continues then:

"SEA's ARC 5.1 (non-Squashing) archival storage format will be the
"fallback" if  either party  is unable or unwilling to support an
alternate method.  The continued use of Echomail software without
prior agreement  of both  the sending  and receiving  nodes which
interferes with  the  distribution  of  echomail  shall  lead  to
disciplinary action  as described  previously in  this  document.
See Section  III.   Examples of prohibited software would include
the use  of  non-standard  echomail  packets  which  can  not  be
processed by  the receiving  system."

With enough compression fanatism someone could shout now: "look, ARC is the fallback when the other side is unable to support my compression". But if we consider all of the text then the main purpose of the echopol would rise: Make sure that echomail can be processed.

 AI>>> I get/send netmail to/from that node periodically. I would be
 AI>>> happy to link with that node if there was any reason to.

 KR>> There is. A periodical link should be secured.

 AI> I periodically get/send netmail to nodes I am not linked with. It's
 AI> not possible or desirable to link and secure to every node for
 AI> possible periodic netmails.

Well, true but why don't you use your secoured links and set up routing?

 AI> Secure links for possible periodic netmail is not necessary.

Just like compressed netmail is not. If you receive test mails only, what size do they have that would need compression?

 AI> When mail arrives compressed then we simply need to decompress it.

As proved by the policies we simply do not need to agree to receive it.

 KR>> This would work without any issues if the sender disables netmail
 KR>> compression.

 AI> Yes, it would. HPT works this way by default but not all
 AI> tossers/mailer do and we need to work with what we get.

No, definitly not.

Do you really want to be forced to handle anything i throw to your system?

What if i use an archive format that requires to pay a serious ammount of money for registration? There is none yet? I'd like to write it, it should be easy merge open source zip and pgp to force you to buy the decryp... decompression key.

Do you really know who "we" are?
Do you know which machines are used for node operation?

My node did run on a P1/133 with 32MB RAM for a long time. An actual compression format that would require 66MB for decompression would crash the system.

If there are tossers that can not turn off compression then they do not conform to the minimum standards of fidonet. Any sysop who use such software risks his node number.

 AI>>> This sysop, I suspect just wanted to test the route on the
 AI>>> return trip. No need to talk about that.

 KR>> Then what is this for? Why should someone do a connect if there
 KR>> is nothing to talk? There is no need to build a road if nobody
 KR>> travels. Paths build up because many are going in the same
 KR>> direction.

 AI> I could only guess since the sysop hasn't told me, so I won't do that.
 AI> I can and do talk to this sysop at times so if there is need to talk
 AI> we will.

Then talk to him. There is need. He does annoy the network. He forces you to ask for a change in software operation. It may result into developer work, wasting valueable dev time for one unwitting sysop.

(i found unwitting by translator. i hope that stands for "he doesn't know what he's doing".)

 AI> I am not asking anyone to travel anywhere they don't want/need to
 AI> travel.

Then don't follow him if he don't want to travel with us.

 KR>> The problem is unsecured inbound compressed netmail.

 AI> I need to decompress archived netmail, that has never been a problem.

Then why it is now? This "new" fault is no issue on your system.

 AI>>> and if there is I would like to get to work on the solution.

 KR>> The solution is turn off compression and/or turn off not
 KR>> necessary tests.

 AI> I don't compress netmail here. I could if a node asked for that but
 AI> none have so it doesn't happen here. Like any node I can control
 AI> output but not input.

Anyone and you can. TALK WITH HIM! Do what fidonet is for. Communicate!

I explained above that sending insecure compressed netmail and so he is annoying according fidonets common practice and policies.

Regards

Kai

--- GoldED+/LNX 1.1.4.7