Date: Fri, 28.09.12 00:46
MvdV>> node that one had no prior contact with.
ml> right... and that info carries on after initial contact, too...
AG> Of course ... until we agree on something different ...
no... even after... if there are no specific overrides, then the nodelist flags
indicate the capabilities... the way i've always seen MN is that no compressed
files of any sort was accepted... all mail files of any type are to be raw FTN
PKT files... netmail and echomail, both...
MvdV>> These additional arrangements may include things as a secure
MvdV>> link, exchange of echomail, file distribution, ... and
ml> that requires a specific override to be manually implemented... are
ml> you saying that you think that every node should have a bunch of
ml> overrides put in place that they have to manage outside of
ml> everything else?
AG> Setting a packet password is an override per se ...
per se... but that's in a different "area" than the nodelist... unless your
software requires that it be compiled into some sort of index but then we're
talking about fogging over what "the nodelist" is and what an "override" is...
AG> unless we've got a session password, we're unsecure ... thus the
AG> default applies -> no compression.
AG> At least my netmail processor doesn't care too much about the
AG> nodelist and MN flags in there.
and there's one of the possible key factors to this... the mailer can easily
distinguish between raw PKTs and any other files destined to the remote
system... no tosser need be involved...
AG> If yours is so much different and makes it more complicated to
AG> override MN, it's not a disaster. Either you care about
AG> compressing things ... then you'll go the extra mile ... or you
AG> don't. Nowadays netmail traffic is low (MN does not affect
AG> echomail at all) and bandwidth is plenty.
agreed to a point... part of that point being that "bandwidth is not plenty"
for many folks...
* Origin: (1:3634/12)