[nos-bbs] B2F bulletin fixes, etc ...

Gustavo Ponza g.ponza at tin.it
Wed May 4 04:25:21 EDT 2011

On Tue, 2011-05-03 at 12:28 -0500, Maiko Langelaar wrote:
> Hi Gus,
> > my new JNOS system is forwarding OK since several hours...
> Sounds good.
> Now, my only complaint about B2F so far is that one can not
> reject bulletins anymore at the proposal level, you have to
> wait now for the COMPLETE payload to be transferred before
> there is any chance to see who the recipient (To:) is.
> I'm not so sure there is really any benefit to use B2F between
> two JNOS systems, the only difference is an extra checksum and
> computation of the extra checksum. And because you now have to
> wait for an ENTIRE payload to be received (no matter how big),
> it is a waste of bandwidth if you wind up rejecting a bunch of
> bulletins anyways.
> Right now, bulletins I do not want just get sent to CHECK area,
> there is no way to *reject* them anymore. Rejects will now only
> occur if the message id in the proposal is a duplicate.
> That's my observations so far anyways ...
> Maiko Langelaar / VE4KLM

Hi Maiko,
the report on my observations / suggestions follows.

73, Gustavo / I0OJJ

May 04, 2011

The B2F forwarding between two JNOS 2.0i (sources as of: Apr 28, 2011):
my results and comments.

1. The FBB forwarding style operates on the FA proposal (bases) lines
where the 'From', the 'Route' and the 'To' fields are displayed to the
forward partner station; in that way, the receiving stations, may decide
to filter the incoming mails in their mailboxes by rejecting one or more
of the unwanted fields.

2. SMTP session: N/A.

3. In the B2F protocol, as implemented into the JNOS, we can see a
previous 'lzhuf' mail compression (just after the two JNOS connected
each other) followed by a FS ++ line, then another 'lzhuf' compression
equivalent to the previous one, and then the sending by using the FC

a. Perhaps, (I think) there is no need to make the first compression.

b. Since the impossibility to select/reject the incoming mails, (then)
on this stage, on behalf of the first compression (or before it, if that
is needed) a previous FA proposal line could be sent (shown) and
challenged, followed by the FS reply (as it appears on the process),
then the lhzuf compression *only* for the accepted mails and finally the
FC forwarding lines.
In that way we can reach our goal and also reduce the operating time.

NOTE: The linux /tmp directory fills up of lzhuf *binmails* and readable
mails generated by the above JNOS processes...

73, Gustavo / I0OJJ  


00:14:00  I0OJJ-8 on port xnet - MBOX (i0ojj) connected
00:14:00  I0OJJ-8 on port xnet - MBOX (i0ojj) forwarding
00:14:02  I0OJJ-8 on port xnet - MBOX (i0ojj) FA B CX2SA ARL KEP ARLK034
00:14:02  I0OJJ-8 on port xnet - MBOX (i0ojj) FA B OK0NAG EU SOLAR
35LOK0NAG011 8068
00:14:02  I0OJJ-8 on port xnet - our FBB response is FS ++
00:14:05  I0OJJ-8 on port xnet - lzhuf uncompress 2175/3830 = 43 percent
00:14:08  I0OJJ-8 on port xnet - lzhuf uncompress 4621/8263 = 44 percent
00:14:11  I0OJJ-8 on port xnet - MBOX (i0ojj) fwd exit


00:14:11 - open SMTP
00:14:11 - SMTP sent job 75473 To: kep at arl From:
cx2sa%cx2sa.lav.ury.sa at i0ojj.ampr.org
00:14:11 - SMTP sent job 75474 To: solar at eu From:
ok0nag%ok0nag.#boh.cze.eu at i0ojj.ampr.org
00:14:11 - close SMTP


00:44:02 - MBOX (ve4klm) connected
00:44:03 - MBOX (ve4klm) forwarding
00:44:03  - lzhuf compress 2261/3974 = 43 percent
00:44:04  - lzhuf compress 4690/8441 = 44 percent
00:44:04 - got FBB response of FS ++
00:44:04 - lzhuf compress 2261/3974 = 43 percent
00:44:04 - lzhuf compress 4690/8441 = 44 percent
00:44:06 - MBOX (ve4klm) sent FC EM arlk034 3974
2267 0
00:44:06 - MBOX (ve4klm) sent FC EM 35lok0nag011
8441 4696 0
00:44:06 - MBOX (ve4klm) fwd exit


More information about the nos-bbs mailing list