On Fri, 04 Mar 2016, Stephen Hurd wrote to mark lewis:

 > s/Usually set to zero\./Usually set to zero when the message is packed\.
 > This  is because the cost field in the local unpacked copy of the message
 > pertains to the actual cost in monetary value to transmit the message from
 > the local system to the destination system\./

 SH> This spec only covers the packet formats.  Any cost field in some
 SH> other file or structure isn't specified here.  I could remove the
 SH> "Usually set to zero" part if you like, though I think having it in
 SH> there as guidance is worthwhile. 

no... it is fine there... i was thinking that an explanation for why it is set
to zero would be helpful...

 SH> I didn't see anything in your discussion about the cost field of
 SH> packets.

if you mean the cost field of a packed message, that's because there is nothing
to talk about, really... the cost field comes from the original MSG format
which the packed message is based on... that's why they are so similar in
form...

if you and i are linked, if my system places a value in the cost field of a
packed message, what is your system supposed to do with that cost value when
your system unpacks that message for processing? the value shouldn't mean
anything to you or your system... it may hamper your system's operation if it
is used for qualifying the mail for sending because your cost to send it on may
be different than mine... it should be zeroed when my system packs the message
to prevent this interference but the receiving system may want to zero it on
reception if it is not already zero... the receiving system may alter the value
to fit their cost structure when they quality the mail for the next hop (eg:
routed netmail being processed on an intermediate system)...

there was an incident some years back in the '90s where a mailer or tosser
would not qualify a message to be sent on to the next hop... it was finally
discovered that the originator had not zeroed the cost field and the
intermediate system's setup didn't allow for mail with a cost value that high
to be sent on... the devs of the packages involved got together and figured out
what needed to be done was to zero the cost field when packing and ignoring or
zeroing the cost field on arrival to avoid the problem... this allowed the
intermediate system(s) to be able to also use the cost field for their needs in
passing the message on... dynamic mailers are the main users of the cost field
but some BSO systems may also use them if they use tools like bonk and
son-of-bonk and similar to manage the mail waiting in their BSO for sending...

)\/(ark