Hi deon,
thank you so much for taking a look at this :).
OK I tracked this down, and the netmails were passed onto 21:3/246.
The reason you were not seeing them on 21:3/242 was related to a bug processing the Via line (your VIA lines are not including a timezone),
and while it is optional, I was calling a date function with a blank
string for a timezone, instead of "null", causing an exception to be
thrown.
Gotcha! :)
To be fair, I couldn't tell for sure wether the netmails to 3/246 (and
others) were delivered or not. It's certainly possible. I was fighting
several battles at once - implementing netmail support myself in my
90's C bbs software, while troubleshooting crashmail configurations
in parallell with expanding my own knowledge on how the ftn protocol
and standards even function to begin with :D. At the same time, trying
to keep the total number of test netmails sent to real people as low
as possible :D. Only once I had the feeling that my configs - and the
way my bbs constructs the netmail .MSG's - both were up to the
standards, I felt I just had to reach out for support ;).
This bug would only have dropped the VIA line from 3/242, so outbound netmails would have been sent without it - as well as clrghouz not
showing them on the "Packets and Files Sent" tab.
Yup, that was the confusing part. I use the "Packets and Files Sent"
tab all the time, to verify inbound and outbound traffic. It has never
failed on me before - which made me assume that as long as the "The
last Netmails received" is empty, it's probably just me doing something
wrong (again) ;).
Btw : To my understanding, Crashmail constructs the VIA line during
SCAN.
We now have :
21:3/242 @20260712.231005 CrashMail II/Linux 1.7
But what we want is :
21:3/242 @20260712.211005.UTC CrashMail II/Linux 1.7
At some point, I might dig into the Crashmail source to see if we can
fix that! :)
Many thanks deon - you're a hero!
Cheers
Peter
--- SklaffKOM v1.33rc1
* Origin: Twilight Node, Solvesborg, Sweden (21:3/242)