why is this happening???

[mark lewis]

1:3634/***@fidonet is known in my binkd config...

1:123/22@ fidonet is NOT known in my binkd config...

they are the same system...

so, why did the inbound mail get put into the unknown directory instead of
1:3634/22's defined filebox???

- 22 Nov 12:06:58 [1] incoming from cpe-071-068-019-115.carolina.res.rr.com
(71.68.19.115)
+ 22 Nov 12:06:58 [3] session with cpe-071-068-019-115.carolina.res.rr.com
(71.68.19.115)
- 22 Nov 12:06:58 [3] OPT MB CRC MD5
- 22 Nov 12:06:58 [3] SYS *Square One Christian BBS
- 22 Nov 12:06:58 [3] ZYZ C.W. Gordon
- 22 Nov 12:06:58 [3] LOC Belmont, NC
- 22 Nov 12:06:58 [3] NDL CM,BINKP,TCP
- 22 Nov 12:06:58 [3] TIME 2010/11/22 12:06:01 -5:00
- 22 Nov 12:06:58 [3] VER Internet Rex 2.31 Win32 (binkp/1.1)
+ 22 Nov 12:06:58 [3] addr: 1:123/***@fidonet
+ 22 Nov 12:06:59 [3] addr: 1:3634/***@fidonet
- 22 Nov 12:06:59 [3] remote is in NR mode
+ 22 Nov 12:06:59 [3] have 0 byte(s) of 0000FE22.MO0
- 22 Nov 12:06:59 [3] receiving 0000FE22.MO0 (784 byte(s), off 0)
+ 22 Nov 12:07:00 [3] 0000FE22.MO0 -> [*path*]\unknown\0000FE22.MO0
22 Nov 12:07:00 [3] got *.mo?, delayed creating [*path*]\mail.sem
+ 22 Nov 12:07:00 [3] rcvd: 0000FE22.MO0 (784, 784.00 CPS, 1:123/***@fidonet)
+ 22 Nov 12:07:00 [3] done (from 1:123/***@fidonet, OK, S/R: 0/1 (0/784 bytes))
22 Nov 12:07:00 [3] session closed, quitting...
22 Nov 12:07:00 [3] Creating [*path*]\mail.sem


)\/(ark

[Peter Knapper]

Hi Mark,

ml> 1:3634/***@fidonet is known in my binkd config...

ml> 1:123/22@ fidonet is NOT known in my binkd config...

ml> they are the same system...

ml> so, why did the inbound mail get put into the unknown
ml> directory instead of 1:3634/22's defined filebox???

Ok, I'll bite....;-)

What was the SOURCE address used for the Mail in Question?

My guess is that if SOURCED from 1:123/22 then its unknown mail, so it goes
Insecure...

However, if its sourced from 1:3634/22, then I have no idea...;-)

Cheers................pk.

[mark lewis]

ml> 1:3634/***@fidonet is known in my binkd config...

ml> 1:123/22@ fidonet is NOT known in my binkd config...

ml> they are the same system...

ml> so, why did the inbound mail get put into the unknown
ml> directory instead of 1:3634/22's defined filebox???

PK> Ok, I'll bite....;-)

PK> What was the SOURCE address used for the Mail in Question?

i don't know... the log snippet i posted is all i have... both addresses were
listed in it...

PK> My guess is that if SOURCED from 1:123/22 then its unknown mail, so
PK> it goes Insecure...

that makes sense but how to tell? must i list all of the remote's fidonet
addresses??

PK> However, if its sourced from 1:3634/22, then I have no idea...;-)

:)

)\/(ark

[Paul Quinn]

Hi! mark,

On 23/11/10 18:40, you wrote to Peter Knapper:

PK>> My guess is that if SOURCED from 1:123/22 then its unknown mail, so
PK>> it goes Insecure...

ml> that makes sense but how to tell? must i list all of the remote's
ml> fidonet addresses??

PK>> However, if its sourced from 1:3634/22, then I have no idea...;-)

ml> :)

Could it be that Papa Bill is listing 1:123/22 as his primary aka, and it's not
defined in binkD as the associated filebox?

The ultimate fix might be that he'll have to have his packer arc-up both aka's
mail into the one bundle, ala how FE can.

Cheers,
Paul.

.... Dear Santa, all I want for x-mas is your list of *bad* girls.

[Peter Knapper]

Hi Mark,

Just a suggestion...


ml> i don't know... the log snippet i posted is all i
ml> have... both addresses were listed in it...

If you had the mail item itself then you should be able to find its source from
one of the control lines (VIA perhaps)...

Cheers...........pk.

[mark lewis]

ml> i don't know... the log snippet i posted is all i
ml> have... both addresses were listed in it...

PK> If you had the mail item itself then you should be able to find its
PK> source from one of the control lines (VIA perhaps)...

the problem that this references is why the inbound traffic was placed in the
unknown folder... this is decided before any files actually transfer...

)\/(ark

[Peter Knapper]

Hi Mark,

ml> i don't know... the log snippet i posted is all i
ml> have... both addresses were listed in it...

PK> If you had the mail item itself then you should be able to find its
PK> source from one of the control lines (VIA perhaps)...

ml> the problem that this references is why the inbound
ml> traffic was placed in the unknown folder... this is
ml> decided before any files actually transfer...

I use a packet sniffing tool (inspecta) to search/display the contents of a
packet before it is touched. My Platform is OS/2 (and inspecta is native to
that) howver I know that inspecta is also available in a DOS version that
probably runs under DOSEMU if thats available (I think you use *nix dont you?)

Cheers................pk.

[mark lewis]

ml> i don't know... the log snippet i posted is all i
ml> have... both addresses were listed in it...

PK> If you had the mail item itself then you should be able to find its
PK> source from one of the control lines (VIA perhaps)...

ml> the problem that this references is why the inbound
ml> traffic was placed in the unknown folder... this is
ml> decided before any files actually transfer...

PK> I use a packet sniffing tool (inspecta) to search/display the
PK> contents of a packet before it is touched. My Platform is OS/2 (and
PK> inspecta is native to that) howver I know that inspecta is also
PK> available in a DOS version that probably runs under DOSEMU if thats
PK> available (I think you use *nix dont you?)

yes, i have both flavors of inspecta but as noted above, the packet files are
NOT in play when binkd decides which directory to put them in... i think i have
to put that system's other address(es) in my binkd config which i will try
shortly once i see what's up with the PKTs that have been arriving...

i only process NETMAIL from my unknown directory and if there is echomail in
them, they are set aside as security violations...

)\/(ark