[nos-bbs] X-BBS-Msg-Type: E Recent Messages

[Gustavo Ponza]

On Tue, 2014-09-16 at 13:12 -0400, Don Moore wrote:
> I'm getting mail ok in jnos but anything that comes to ve3zda is
> putting smtp into a cycle that it cannot get out of .  It's as though
> jnos does not know itself.  I've made many checks of the rewrite file
> and see absolutely no errors in there.  The only way for me to get out
> of the problem short of forcing a jnos restart is to stop smtp, kill
> the smtp number then restart smtp.  Others are also having this
> problem and in each of those cases we are not using the most current
> version of jnos even though at one point we were and that has made no
> difference.  Messages arriving to anyone else is processed just fine.


Some odd things were experienced here when the 'mbox smtptoo on' is
present on the JNOS2 AX.25 forwarding chain toward us.
The newest resync'ed JNOS2 version is the most free as for the minor
bugs and for features and stability so it should be the 'only'
adopted.


On 14-09-16 07:00 PM, Don Moore wrote:
> actually, because the message is not delivered to the mailbox I can't 
> see the message itself only the job in the smtp and the mail log
which 
> shows where it's trying to be delivered and below is an example from 
> that log...
> Tue Sep 16 16:02:22 2014 queue job 51934 To: ve3zda From: 
> ve3zda at ve3zda.ampr.org <mailto:ve3zda at ve3zda.ampr.org>
> Tue Sep 16 16:02:27 2014 queue job 51937 To: ve3zda at
ve3zda.ampr.org 
> <mailto:ve3zda at ve3zda.ampr.org> From: ve3zda at ve3zda.ampr.org 
> <mailto:ve3zda at ve3zda.ampr.org>

---------


As per my understanding and per my knowledge the above loop may be
caused by an 'r' (rescan command) found at the very beginning
of the 'rewrite' file, and so:

JNOS rescans the rewrite file from the beginning, attempting to
match the new destination address with one of the templates.

... and never finding its 'destination' as per the above statement.

Furthermore, the rewrite file contains data used to cause SMTP
to deliver to a specific location.

The result of rewriting determines whether:

- an incoming message is stored in an area (and, which area receives
  the message);
- an incoming message is stored into /spool/mqueue for handling by
  SMTP.

The rewrite file, through SMTP, performs a one-to-one mapping between
a message's destination (the “To:” field) addresses as received by JNOS,
and the special destination addresses (public or local areas) as
actually used by JNOS.
The “To:” field text is not modified by the mapping process.

Hope to add some ideas to solve the problem.

73, gus i0ojj

> 
> On Tue, Sep 16, 2014 at 12:18 PM, Gustavo Ponza <g.ponza at tin.it>
> wrote:
>         Just arrived here from VE3CGH another type E!
>         One or more softwares in the R-lines below is
>         the cause of that bad formatting.
>         
>         gus / i0ojj
>         
>         From vk4wit%ve3cgh at i0ojj.ampr.org Tue Sep 16 16:10:25 2014
>         Received: from i0ojj.ampr.org by i0ojj.ampr.org (JNOS2.0j.6r)
>         with SMTP
>             id AA152688 ; Tue, 16 Sep 2014 16:10:25 +0200
>         Date: Tue, 16 Sep 2014 16:10:25 +0200
>         Message-Id: <5004_vk4wit at ve3cgh.bbs>
>         From: vk4wit%ve3cgh.bbs at i0ojj.ampr.org
>         To: qnews at vknet
>         Subject: Townsville Amateur Radio Club Weekly Digest 16092014
>         X-BBS-Msg-Type: E
>         X-JNOS-User-Port: Telnet   (ve3cgh @ 44.135.83.22)  -> Sending
>         message
>         X-Forwarded-To: i0ojj
>         
>         R:140916/1354Z @:VE2JOS.#MTL.QC.CAN.NOAM #:9505 [Montreal]
>         $:5004_VK4WIT
>         R:140916/1328Z @:VK2DOT.CC.NSW.AUS.OC [Niagara] #:34100
>         XSERV500f
>         R:140916/1328Z @:VK4TUB.#NQ.QLD.AUS.OC #:25426 [Townsville Qld
>         Oz]
>         R:140916/1327Z @:VK4WIT.#NQ.QLD.AUS.OC #:5004 [Townsville Qld
>         Oz] $:5004_VK4WIT
>         
>         From: VK4WIT at VK4WIT.#NQ.QLD.AUS.OC
>         To  : QNEWS at VKNET
>         
>         <snip>
>         
>         
>         On 09/16/2014 02:27 AM, Charles Hargrove wrote:
>         
>                 Since this problem with "X-BBS-Msg-Type: E" messages
>                 became an issue a few
>                 weeks ago, I have been doing some research of the
>                 various FBB bulletin types
>                 and how JNOS deals with it.  With the help of Ted,
>                 VE3CGH, we seem to have it
>                 narrowed down to a simple procedure.
>                 
>                 If you have "mbox fbb 3" in your autoexec.nos file,
>                 create an "mbox nob2f"
>                 entry for each callsign that you forward with.  The
>                 only time that you would
>                 not do this is if you have WL2K in your forward.bbs
>                 file.  The reason is that
>                 if you negotiate B2F with someone, it says that you
>                 will send or receive a
>                 bulletin that is compressed and encapsulated as this
>                 is the normal Winlink
>                 protocol.  What seems to happen is that you will
>                 receive the bulletin, strip
>                 off any field after the @ and then add the from data
>                 of the station that sent
>                 you the message.  If the original message came from
>                 g4apl at gb7cip and it is
>                 being forwarded to me by f8coj at f8coj, then my system
>                 strips off the gb7cip
>                 and changes the from address to g4apl at f8coj.bbs!  This
>                 will definitely cause
>                 any SR on my end to attempt to send the message to the
>                 wrong BBS.  Also,
>                 there are other downstream BBS stations that don't
>                 like "X-BBS-Msg-Type: E".
>                 
>                 Since Ted and I made the changes, the problem goes
>                 away.  I have also passed
>                 the word to other forwarding partners of mine, that
>                 were attempting to pass
>                 a bulletin with B2F enabled, to also make the changes
>                 on their system.  Let's
>                 see if this solves it for everyone.
>                 
>                 --
>                 Charles J. Hargrove - N2NOV
>                 NYC ARECS/RACES Citywide Radio Officer/Skywarn Coord.
>