Hey Rob,

I noticed a rather interesting bug in Synchronet the other day. I wanted to be able to keep netmail received and sent in the netmail directory, /sbbs/netmail. So I added the -d option to sbbsecho when tossing in/out.

The problem: FTN Netmail sent from Synchronet would get exported to the netmail directory with sbbsecho, not deleted, packed to BSO outbound.

While all that's fine, the problem is next time sbbsecho runs like that,
it will send it again. And again... And again.. Endlessly until it's deleted by other means.

The cause: sbbsecho instead of deleting is not marking the netmail as Sent, keeping it Unsent, so it repeatedly packs it and sends it every time. When not deleting netmail it should at leas mark it Sent and not pack previously sent netmails.

Kinda a big bug IMHO. :)

)))[Psi-Jack -//- Decker]

... What do you mean? You actually read this Tagline?!?

---
þ Synchronet þ Decker's Heaven -//- bbs.deckersheaven.com

Re: sbbsecho and -d
By: Psi-Jack to Digital Man on Tue Jul 21 2015 05:24 pm

Hey Rob,

I noticed a rather interesting bug in Synchronet the other day. I wanted to be able to keep netmail received and sent in the netmail directory, /sbbs/netmail. So I added the -d option to sbbsecho when tossing in/out.

The problem: FTN Netmail sent from Synchronet would get exported to the netmail directory with sbbsecho, not deleted, packed to BSO outbound.

SBBSecho doesn't export netmail. Synchronet (sbbs) creates the .msg netmail files directly.

While all that's fine, the problem is next time sbbsecho runs like that,
it will send it again. And again... And again.. Endlessly until it's deleted by other means.

I think you mean it will pack it. The "sending" is done by the mailer.

The cause: sbbsecho instead of deleting is not marking the netmail as Sent, keeping it Unsent, so it repeatedly packs it and sends it every time. When not deleting netmail it should at leas mark it Sent and not pack previously sent netmails.

Technically, the message is not sent until the mailer sends it and SBBSecho doesn't know when/if that happens. In any case, I'll give your suggestion a shot and hopefully it doesn't stop netmail from being sent by mailers (because the "SENT" flag is now set before the mailer actually sees the netmail message).

Kinda a big bug IMHO. :)

Your editorial comment not withstanding, the "bug" is how SBBSecho has operated
for over 20 years and either no one recognized this behavior as a problem or just never reported it before. In any case, I made the change you requested. Let me know how it works for you.

digital man

Synchronet "Real Fact" #30:
The Synchronet IRC server (ircd) was written in JS by Randy Sommerfeld (Cyan). Norco, CA WX: 77.8øF, 71.0% humidity, 8 mph SE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: sbbsecho and -d
By: Digital Man to Psi-Jack on Tue Jul 21 2015 06:05 pm

Re: sbbsecho and -d
By: Psi-Jack to Digital Man on Tue Jul 21 2015 05:24 pm

Hey Rob,

I noticed a rather interesting bug in Synchronet the other day. I
wanted to be able to keep netmail received and sent in the netmail
directory, /sbbs/netmail. So I added the -d option to sbbsecho when
tossing in/out.
The problem: FTN Netmail sent from Synchronet would get exported to
the netmail directory with sbbsecho, not deleted, packed to BSO
outbound.

SBBSecho doesn't export netmail. Synchronet (sbbs) creates the .msg netmail files directly.

While all that's fine, the problem is next time sbbsecho runs like
that, it will send it again. And again... And again.. Endlessly until
it's deleted by other means.

I think you mean it will pack it. The "sending" is done by the mailer.

True true. :)

The cause: sbbsecho instead of deleting is not marking the netmail as
Sent, keeping it Unsent, so it repeatedly packs it and sends it every
time. When not deleting netmail it should at leas mark it Sent and not
pack previously sent netmails.

Technically, the message is not sent until the mailer sends it and SBBSecho doesn't know when/if that happens. In any case, I'll give your suggestion a shot and hopefully it doesn't stop netmail from being sent by mailers (because the "SENT" flag is now set before the mailer actually sees the netmail message).

Well, binkd mails it, I'm guessing because sbbsecho packs it up into a PKT zip, however...

Kinda a big bug IMHO. :)

Your editorial comment not withstanding, the "bug" is how SBBSecho has operated for over 20 years and either no one recognized this behavior as a problem or just never reported it before. In any case, I made the change you requested. Let me know how it works for you.

The result was very very odd behavior. It packs it, it flags it. The mailer sends it. I was testing versus 1:135/371 to 1:135/371.1 and it showed that on the main node. When it was recieved by the point node mailer, sbbsecho unpacked it, claimed it was addressed to z:n/n and not z:n/n.p, so it packed it back to z:n/n as an empty netmail. z:n/p received it, saw an empty netmail, killed it, packed an empty netmail back to the point node, killing the original 1.msg that was formerly there somehow, then the point receives that, sees an empty netmail, kills it. Thus ends the back and fourth cycle.

I'm guessing that nobody has ever used sbbsecho's -d flag to actually keep their netmail, which is exactly how I found this issue to begin with.

My intended goal was to be able to actually see netmail that's been sent and received, since within Synchronet itself as well as use that same netmail directory with golded so I can do more than Synchronet currently can in regards to netmail, and you cannot see netmail posted by Synchronet, likely because what you said earlier, synchronet itself writes the *.msg files, then sbbsecho packs it up for the mailer. Since sbbsecho usually deletes netmail it packs, by adding the -d switch to sbbsecho to keep them from being deleted, I was able to see this specific issue.

I do not fully completely understand how the whole concept works entirely. I do know, that binkd itself doesn't touch the netmail files. I'm guessing that sbbsecho is packing it into a zip, puts that pkt into the outbound directory, sets up an appropriate BSO file according to the destination and delivery flavor (out, cut, hut, etc)... And that's it. So the netmail would never get flagged sent.

)))[Psi-Jack -//- Decker]

---
þ Synchronet þ Decker's Heaven -//- bbs.deckersheaven.com

Re: sbbsecho and -d
By: Psi-Jack to Digital Man on Wed Jul 22 2015 01:52 am

Re: sbbsecho and -d
By: Digital Man to Psi-Jack on Tue Jul 21 2015 06:05 pm

Re: sbbsecho and -d
By: Psi-Jack to Digital Man on Tue Jul 21 2015 05:24 pm

Hey Rob,

I noticed a rather interesting bug in Synchronet the other day. I
wanted to be able to keep netmail received and sent in the netmail
directory, /sbbs/netmail. So I added the -d option to sbbsecho when
tossing in/out.
The problem: FTN Netmail sent from Synchronet would get exported to
the netmail directory with sbbsecho, not deleted, packed to BSO
outbound.

SBBSecho doesn't export netmail. Synchronet (sbbs) creates the .msg netmail files directly.

While all that's fine, the problem is next time sbbsecho runs like
that, it will send it again. And again... And again.. Endlessly until
it's deleted by other means.

I think you mean it will pack it. The "sending" is done by the mailer.

True true. :)

The cause: sbbsecho instead of deleting is not marking the netmail as
Sent, keeping it Unsent, so it repeatedly packs it and sends it every
time. When not deleting netmail it should at leas mark it Sent and not
pack previously sent netmails.

Technically, the message is not sent until the mailer sends it and SBBSecho doesn't know when/if that happens. In any case, I'll give your suggestion a shot and hopefully it doesn't stop netmail from being sent by mailers (because the "SENT" flag is now set before the mailer actually sees the netmail message).

Well, binkd mails it, I'm guessing because sbbsecho packs it up into a PKT zip, however...

Kinda a big bug IMHO. :)

Your editorial comment not withstanding, the "bug" is how SBBSecho has operated for over 20 years and either no one recognized this behavior as a problem or just never reported it before. In any case, I made the change you requested. Let me know how it works for you.

The result was very very odd behavior. It packs it, it flags it. The mailer sends it. I was testing versus 1:135/371 to 1:135/371.1 and it showed that on the main node. When it was recieved by the point node mailer, sbbsecho unpacked it, claimed it was addressed to z:n/n and not z:n/n.p, so it packed it back to z:n/n as an empty netmail. z:n/p received it, saw an empty netmail, killed it, packed an empty netmail back to the point node, killing the original 1.msg that was formerly there somehow, then the point receives that, sees an empty netmail, kills it. Thus ends the back and fourth cycle.

There was a bug in my implementation of your request. I've now fixed that bug. Please try again.

If you continue to have a problem, please send me a copy of the .msg file before and after SBBSecho runs and packs it.

I'm guessing that nobody has ever used sbbsecho's -d flag to actually keep their netmail, which is exactly how I found this issue to begin with.

Or they did so with an arcmail/attach-style mailer (rather than BSO/FLO).

My intended goal was to be able to actually see netmail that's been sent and received, since within Synchronet itself as well as use that same netmail directory with golded so I can do more than Synchronet currently can in regards to netmail, and you cannot see netmail posted by Synchronet, likely because what you said earlier, synchronet itself writes the *.msg files, then sbbsecho packs it up for the mailer. Since sbbsecho usually deletes netmail it packs, by adding the -d switch to sbbsecho to keep them from being deleted, I was able to see this specific issue.

Which issue?

I do not fully completely understand how the whole concept works entirely. I do know, that binkd itself doesn't touch the netmail files.

Being a BSO/FLO-style mailer, Binkd only deals with packets and never with FTS-1 style "stored messages" (the so-called .msg files). Here's a reference document I wrote up with excerpts from the BinkleyTerm docs: http://wiki.synchro.net/ref:fidonet_files

I'm guessing
that sbbsecho is packing it into a zip, puts that pkt into the outbound directory, sets up an appropriate BSO file according to the destination and delivery flavor (out, cut, hut, etc)... And that's it. So the netmail would never get flagged sent.

Close. Packets and zip files are not the same thing. EchoMail *bundles* are (usually) zipped collections of packets. NetMail packets are not usually bundled (or zipped).

digital man

Synchronet "Real Fact" #16:
"Vertrauen" (ver-trow-en) translates to "trust" in German, and was a band name. Norco, CA WX: 81.7øF, 59.0% humidity, 12 mph SE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: sbbsecho and -d
By: Digital Man to Psi-Jack on Wed Jul 22 2015 02:25 pm

I noticed a rather interesting bug in Synchronet the other day. I
wanted to be able to keep netmail received and sent in the netmail
directory, /sbbs/netmail. So I added the -d option to sbbsecho when
tossing in/out.
The problem: FTN Netmail sent from Synchronet would get exported to
the netmail directory with sbbsecho, not deleted, packed to BSO
outbound.

The cause: sbbsecho instead of deleting is not marking the netmail
as Sent, keeping it Unsent, so it repeatedly packs it and sends it
every time. When not deleting netmail it should at leas mark it
Sent and not pack previously sent netmails.

Technically, the message is not sent until the mailer sends it and
SBBSecho doesn't know when/if that happens. In any case, I'll give
your suggestion a shot and hopefully it doesn't stop netmail from
being sent by mailers (because the "SENT" flag is now set before
the mailer actually sees the netmail message).

Per what you say later on in this, you are correct, though with BSO/FLO, it's technically "sent" as soon as it's packed. :) With ArchMail/Attach style, those would touch the Stored Messages and flag them sent when they were. Now that you reminded me of this. ;)

Well, binkd mails it, I'm guessing because sbbsecho packs it up into a
PKT zip, however...

Kinda a big bug IMHO. :)

Your editorial comment not withstanding, the "bug" is how SBBSecho
has operated for over 20 years and either no one recognized this
behavior as a problem or just never reported it before. In any
case, I made the change you requested. Let me know how it works
for you.

The result was very very odd behavior. It packs it, it flags it. The
mailer sends it. I was testing versus 1:135/371 to 1:135/371.1 and it
showed that on the main node. When it was recieved by the point node
mailer, sbbsecho unpacked it, claimed it was addressed to z:n/n and
not z:n/n.p, so it packed it back to z:n/n as an empty netmail. z:n/p
received it, saw an empty netmail, killed it, packed an empty netmail
back to the point node, killing the original 1.msg that was formerly
there somehow, then the point receives that, sees an empty netmail,
kills it. Thus ends the back and fourth cycle.

There was a bug in my implementation of your request. I've now fixed that bug. Please try again.

If you continue to have a problem, please send me a copy of the .msg file before and after SBBSecho runs and packs it.

I've thoroughly tested things out, commented on IRC too BTW, dunno if you are paying attention there or not.

SBBSEcho flags the message Sent as expected, packs it, and the mailer sends it. Endpoint receives it, sees it's to the right node (in this case a point node, before it was breaking and sending the netmail back, r260 fixes that). But next sbbsecho run packs it again re-sending it.

Line 5053: MSG_SENT needs to be FIDO_SENT, I tested that in a local code change and it worked, reporting it's already been sent as this code change included.

I'm guessing that nobody has ever used sbbsecho's -d flag to actually
keep their netmail, which is exactly how I found this issue to begin
with.

Or they did so with an arcmail/attach-style mailer (rather than BSO/FLO).

Perhaps instead of determining if they used -d or not, perhaps determining which mailer type is being used instead. After things are settled and normalized. :)

My intended goal was to be able to actually see netmail that's been
sent and received, since within Synchronet itself as well as use that
same netmail directory with golded so I can do more than Synchronet
currently can in regards to netmail, and you cannot see netmail posted
by Synchronet, likely because what you said earlier, synchronet itself
writes the *.msg files, then sbbsecho packs it up for the mailer.
Since sbbsecho usually deletes netmail it packs, by adding the -d
switch to sbbsecho to keep them from being deleted, I was able to see
this specific issue.

Which issue?

In Synchronet, when I sent a Netmail, I was unable to see the netmail's I've sent. Only the logged history that it was sent. If I wanted to go back and re-read that, due to a reply that wasn't fully quoted enough to recollect from.

Synchronet, as you said, would directly write to the OPUS .msg files, but also at the same time, /not/ store the sent message into the email message base as a sent message. sbbsecho would pack it and delete it, so it was gone for good.

I have the option "Kill Sent Netmail" turned off, yet it always gets killed.

That's the issue I tried to describe. ;)

I do not fully completely understand how the whole concept works
entirely. I do know, that binkd itself doesn't touch the netmail
files.

Being a BSO/FLO-style mailer, Binkd only deals with packets and never with FTS-1 style "stored messages" (the so-called .msg files). Here's a reference document I wrote up with excerpts from the BinkleyTerm docs: http://wiki.synchro.net/ref:fidonet_files

There we go! Now I'm back on track. I mostly used ArchMail/Attach mailers as I hated BSO-style stuff back way back when. InterMail was my demon of choice, versus FrontDoor, though. I don't even know what D'Bridge uses, but with D'Bridge 4.0 coming to Linux sometime, I'll be finding out. :)

I'm guessing
that sbbsecho is packing it into a zip, puts that pkt into the
outbound directory, sets up an appropriate BSO file according to the
destination and delivery flavor (out, cut, hut, etc)... And that's it.
So the netmail would never get flagged sent.

Close. Packets and zip files are not the same thing. EchoMail *bundles* are (usually) zipped collections of packets. NetMail packets are not usually bundled (or zipped).

So, exactly as I said earlier. Based on this, it's "sent" as soon as it's packed, because it's been processed, rather than handled by the mailer.


So, to re-itterate what I tested on sbbsecho r260:
Netmail from 1:135/371 sent to 1:135/371.1 works: That is, Sent is set in the N.msg file (confirmed by GoldEd+ and msgEd), the recipient system--also a
point node which was failing before--received the netmail and imported it; however MSG_SENT vs FIDO_SENT causes the netmail to be repeated packed and sent.

Netmail from 1:135/371.1 sent to 1:135/371 works 100% as designed. 1 limitation of this is sbbsecho directly imports this into Synchronet and does not provide a N.msg file of it. It would be extremely nice if it would, as it would allow one to keep a populated sent and received OPUS message base for external use with tools like GoldEd+, or Husky msgEd.
This though is not a bug, but a feature request for that specific functionality. Perhaps if importing has the -d option, it could also drop a N.msg appropriate after importing to Synchronet?

Without the -d option on sbbsecho, no differences appear since r258, before this adjustment.

)))[Psi-Jack -//- Decker]

---
þ Synchronet þ Decker's Heaven -//- bbs.deckersheaven.com

Re: sbbsecho and -d
By: Psi-Jack to Digital Man on Wed Jul 22 2015 07:09 pm

The result was very very odd behavior. It packs it, it flags it. The
mailer sends it. I was testing versus 1:135/371 to 1:135/371.1 and it
showed that on the main node. When it was recieved by the point node
mailer, sbbsecho unpacked it, claimed it was addressed to z:n/n and
not z:n/n.p, so it packed it back to z:n/n as an empty netmail. z:n/p
received it, saw an empty netmail, killed it, packed an empty netmail
back to the point node, killing the original 1.msg that was formerly
there somehow, then the point receives that, sees an empty netmail,
kills it. Thus ends the back and fourth cycle.

There was a bug in my implementation of your request. I've now fixed that bug. Please try again.

If you continue to have a problem, please send me a copy of the .msg file before and after SBBSecho runs and packs it.

I've thoroughly tested things out, commented on IRC too BTW, dunno if you are paying attention there or not.

Not today.

SBBSEcho flags the message Sent as expected, packs it, and the mailer sends it. Endpoint receives it, sees it's to the right node (in this case a point node, before it was breaking and sending the netmail back, r260 fixes that). But next sbbsecho run packs it again re-sending it.

Line 5053: MSG_SENT needs to be FIDO_SENT, I tested that in a local code change and it worked, reporting it's already been sent as this code change included.

Got it, committed it. Thanks.

I'm guessing that nobody has ever used sbbsecho's -d flag to actually
keep their netmail, which is exactly how I found this issue to begin
with.

Or they did so with an arcmail/attach-style mailer (rather than BSO/FLO).

Perhaps instead of determining if they used -d or not, perhaps determining which mailer type is being used instead. After things are settled and normalized. :)

I'm not sure what you're suggesting. The feature is question is the "Pack Netmail" feature of SBBSecho which is only used with BSO/FLO-style mailers.

My intended goal was to be able to actually see netmail that's been
sent and received, since within Synchronet itself as well as use that
same netmail directory with golded so I can do more than Synchronet
currently can in regards to netmail, and you cannot see netmail posted
by Synchronet, likely because what you said earlier, synchronet itself
writes the *.msg files, then sbbsecho packs it up for the mailer.
Since sbbsecho usually deletes netmail it packs, by adding the -d
switch to sbbsecho to keep them from being deleted, I was able to see
this specific issue.

Which issue?

In Synchronet, when I sent a Netmail, I was unable to see the netmail's I've sent. Only the logged history that it was sent. If I wanted to go back and re-read that, due to a reply that wasn't fully quoted enough to recollect from.

Synchronet, as you said, would directly write to the OPUS .msg files, but also at the same time, /not/ store the sent message into the email message base as a sent message. sbbsecho would pack it and delete it, so it was gone for good.

Okay, I don't really see that as an "issue".

I have the option "Kill Sent Netmail" turned off, yet it always gets killed.

That's the issue I tried to describe. ;)

I think you're talking about the option SCFG->Networks->FidoNet->Kill Netmail After Sent. With that option off, the "KILLSENT" flag in the FTS-1 stored message is not set, which would only effect FD/attach-style mailers. Since BSO/FLO-style mailers don't delete netmail, that flag has no effect.

I do not fully completely understand how the whole concept works
entirely. I do know, that binkd itself doesn't touch the netmail
files.

Being a BSO/FLO-style mailer, Binkd only deals with packets and never with FTS-1 style "stored messages" (the so-called .msg files). Here's a reference document I wrote up with excerpts from the BinkleyTerm docs: http://wiki.synchro.net/ref:fidonet_files

There we go! Now I'm back on track. I mostly used ArchMail/Attach mailers as I hated BSO-style stuff back way back when. InterMail was my demon of choice, versus FrontDoor, though. I don't even know what D'Bridge uses, but with D'Bridge 4.0 coming to Linux sometime, I'll be finding out. :)

I used all of the above. My recollection is D'bridge is also an attach-style mailer.

I'm guessing
that sbbsecho is packing it into a zip, puts that pkt into the
outbound directory, sets up an appropriate BSO file according to the
destination and delivery flavor (out, cut, hut, etc)... And that's it.
So the netmail would never get flagged sent.

Close. Packets and zip files are not the same thing. EchoMail *bundles* are (usually) zipped collections of packets. NetMail packets are not usually bundled (or zipped).

So, exactly as I said earlier. Based on this, it's "sent" as soon as it's packed, because it's been processed, rather than handled by the mailer.

That's not how that attribute flag is defined in the FTSC specs, but if it makes you happy, I guess that's what matters.

digital man

Synchronet "Real Fact" #56:
Synchronet introduced Telnet, FTP, SMTP and POP3 support w/v3.00a-Win32 in 2000.
Norco, CA WX: 81.0øF, 58.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: sbbsecho and -d
By: Digital Man to Psi-Jack on Wed Jul 22 2015 04:57 pm

I've thoroughly tested things out, commented on IRC too BTW, dunno if
you are paying attention there or not.

Not today.

Heh, OKay. I've been paying attention to them by seeing the cvs updates. ;)

SBBSEcho flags the message Sent as expected, packs it, and the mailer
sends it. Endpoint receives it, sees it's to the right node (in this
case a point node, before it was breaking and sending the netmail
back, r260 fixes that). But next sbbsecho run packs it again

re-sending it.

Line 5053: MSG_SENT needs to be FIDO_SENT, I tested that in a local
code change and it worked, reporting it's already been sent as this
code change included.

Got it, committed it. Thanks.

Thanks! This solves that issue entirely so far that I can see. At least sent Netmail can be kept, as well as locally created netmail outside of Synchronet, like GoldEd+, msgEd, etc..

Perhaps instead of determining if they used -d or not, perhaps
determining which mailer type is being used instead. After things are
settled and normalized. :)

I'm not sure what you're suggesting. The feature is question is the "Pack Netmail" feature of SBBSecho which is only used with BSO/FLO-style mailers.

Hmmm.. You have a point. Okay, makes sense then now. Sorry to be confusing on the matter. Like I said, I was more accustomed to ArcMail/Attach systems than BSO.

The thing I now remember as to why I hated BSO/FLO style mail handling,
beyond the fact I always hated the slugish, slow, and ugly little BinkleyTerm, that for color required to you run a TSR (was it ansi.sys/com, or something else? LOL). --- Was that BSO style mail would leave very little to knowing what happened to your mail. Was it sent? You could tell at least it was packed and that the mailer sent something resembling a packet, but not if that specific message was actually sent. FD/IM/D'B those Netmail flags meant everything, including that it was actually sent.

Though, like sbbsecho, pretty much every packer that did BSO/FLO, also let you keep netmail, or delete it. They just wouldn't continue re-packing it everytime. Hehe

In Synchronet, when I sent a Netmail, I was unable to see the
netmail's I've sent. Only the logged history that it was sent. If I
wanted to go back and re-read that, due to a reply that wasn't fully
quoted enough to recollect from.

Synchronet, as you said, would directly write to the OPUS .msg files,
but also at the same time, /not/ store the sent message into the email
message base as a sent message. sbbsecho would pack it and delete it,
so it was gone for good.

Okay, I don't really see that as an "issue".

Personal preference I guess. But it's sometimes quite important regardless. In example, FidoNet Voting and Election times. You send a Netmail to a specific host with your vote and a "password" (as they call it, really just a personal anonymous token to be used for validation).

In times that I'm actually going to be involved with that, keeping a record of my netmail I sent with that token is a bit important, cause I can verify and /see/ that record of it. Honestly I don't know why Synchronet treats NetMail (E-Mail too IIRC), with such a disregard for keeping a copy of what was sent on record until I choose to delete it. Local mail, no problem. I send someone on my BBS an private email, I can see that and later delete it, or let the system clean it up when expiration time comes. NetMail, Internet E-Mail, or QWKNet Mail (maybe the latter too, not sure?) Once posted, it's gone forever.

That's the overall "issue" I'm trying to solve. And IF anyone else here agrees, I'd encourage to speak up, too. :)

I have the option "Kill Sent Netmail" turned off, yet it always gets killed.
That's the issue I tried to describe. ;)

I think you're talking about the option SCFG->Networks->FidoNet->Kill Netmail After Sent. With that option off, the "KILLSENT" flag in the FTS-1 stored message is not set, which would only effect FD/attach-style mailers. Since BSO/FLO-style mailers don't delete netmail, that flag has no effect.

Ahhhh... Yes.. That makes sense. Again, sorry, confused between FD/IM vs
BSO methods. I knew all this stuff 20 years ago. But it's been about 20 years. Hard to retain stuff you don't even look at for so long. :)

mailers as I hated BSO-style stuff back way back when. InterMail was
my demon of choice, versus FrontDoor, though. I don't even know what
D'Bridge uses, but with D'Bridge 4.0 coming to Linux sometime, I'll be
finding out. :)

I used all of the above. My recollection is D'bridge is also an attach-style mailer.

Hmmm. I don't really know. Though I do know exactly whom to ask, via FidoNet! :D Since he's announced D'Bridge 4.0 will be available for Linux. Honestly, I hated D'Bridge back in the day. But today, if it's at least attach-style like you say, I'm looking even more forward to it. heh

So, exactly as I said earlier. Based on this, it's "sent" as soon as
it's packed, because it's been processed, rather than handled by the
mailer.

That's not how that attribute flag is defined in the FTSC specs, but if it makes you happy, I guess that's what matters.

It does, actually, make me happy that is. One little thing allowing half my netmail to be available in a cross-platform usable format (OPUS).

What's the chances of getting sbbsecho's netmail /import/ to drop a OPUS .msg file down, at least if -d is set in sbbsecho? :)

)))[Psi-Jack -//- Decker]

---
þ Synchronet þ Decker's Heaven -//- bbs.deckersheaven.com

Re: sbbsecho and -d
By: Psi-Jack to Digital Man on Wed Jul 22 2015 08:55 pm

SBBSEcho flags the message Sent as expected, packs it, and the mailer
sends it. Endpoint receives it, sees it's to the right node (in this
case a point node, before it was breaking and sending the netmail
back, r260 fixes that). But next sbbsecho run packs it again

re-sending it.

Line 5053: MSG_SENT needs to be FIDO_SENT, I tested that in a local
code change and it worked, reporting it's already been sent as this
code change included.

Got it, committed it. Thanks.

Thanks! This solves that issue entirely so far that I can see. At least sent Netmail can be kept, as well as locally created netmail outside of Synchronet, like GoldEd+, msgEd, etc..

Okay, good to hear.

Perhaps instead of determining if they used -d or not, perhaps
determining which mailer type is being used instead. After things are
settled and normalized. :)

I'm not sure what you're suggesting. The feature is question is the "Pack Netmail" feature of SBBSecho which is only used with BSO/FLO-style mailers.

Hmmm.. You have a point. Okay, makes sense then now. Sorry to be confusing on the matter. Like I said, I was more accustomed to ArcMail/Attach systems than BSO.

Me too. I went from FD to IM to D'Bridge and then I think back to IM. I don't remember now. Anyway, with FTN over TCP/IP, BinkD seemed the way to go, so I've
been using that for the past 15 years or so.

The thing I now remember as to why I hated BSO/FLO style mail handling, beyond the fact I always hated the slugish, slow, and ugly little BinkleyTerm, that for color required to you run a TSR (was it ansi.sys/com, or something else? LOL). --- Was that BSO style mail would leave very little to knowing what happened to your mail. Was it sent? You could tell at least it was packed and that the mailer sent something resembling a packet, but not if that specific message was actually sent. FD/IM/D'B those Netmail flags meant everything, including that it was actually sent.

Both systems are kludgey (in my view) and very hard to debug.

Though, like sbbsecho, pretty much every packer that did BSO/FLO, also let you keep netmail, or delete it. They just wouldn't continue re-packing it everytime. Hehe

The only other echomail/tosser program I've ever used was gecho and I paired that with a program I wrote called SBBSFIDO. SBBSFIDO was replaced with SBBSecho and initially only supported FD/attach-style mailers. Later, King Drafus (Allen) added BSO/FLO-style mailer support and I've been maintaining it since (with Deuce's and others' help).

In Synchronet, when I sent a Netmail, I was unable to see the
netmail's I've sent. Only the logged history that it was sent. If I
wanted to go back and re-read that, due to a reply that wasn't fully
quoted enough to recollect from.

Synchronet, as you said, would directly write to the OPUS .msg files,
but also at the same time, /not/ store the sent message into the email
message base as a sent message. sbbsecho would pack it and delete it,
so it was gone for good.

Okay, I don't really see that as an "issue".

Personal preference I guess. But it's sometimes quite important regardless. In example, FidoNet Voting and Election times. You send a Netmail to a specific host with your vote and a "password" (as they call it, really just a personal anonymous token to be used for validation).

In times that I'm actually going to be involved with that, keeping a record of my netmail I sent with that token is a bit important, cause I can verify and /see/ that record of it. Honestly I don't know why Synchronet treats NetMail (E-Mail too IIRC), with such a disregard for keeping a copy of what was sent on record until I choose to delete it. Local mail, no problem. I send someone on my BBS an private email, I can see that and later delete it, or let the system clean it up when expiration time comes. NetMail, Internet E-Mail, or QWKNet Mail (maybe the latter too, not sure?) Once posted, it's gone forever.

Only FTN netmail is treated this way. Internet and QWKnet netmail are stored in
the SMB (data/mail.*) and availble to read-after-sent. The reason SBBS directly
stores .msg files is historic and one of the things I have on the to-do list to
change. Although SBBSecho is fundamentally an echomail program, it could export
FTN netmail from SMB. This would change what is now a 1-step process (for FD/attach-style mailers) or a 2-step process (for BSO/FLO-style mailers) to a 2
or 3-step process, but I definitely see the benefits and it would open up other
possibilities (e.g. gating FTN mail through SMTP).

That's the overall "issue" I'm trying to solve. And IF anyone else here agrees, I'd encourage to speak up, too. :)

I have the option "Kill Sent Netmail" turned off, yet it always gets killed.
That's the issue I tried to describe. ;)

I think you're talking about the option SCFG->Networks->FidoNet->Kill Netmail After Sent. With that option off, the "KILLSENT" flag in the FTS-1 stored message is not set, which would only effect FD/attach-style mailers. Since BSO/FLO-style mailers don't delete netmail, that flag has no effect.

Ahhhh... Yes.. That makes sense. Again, sorry, confused between FD/IM vs
BSO methods. I knew all this stuff 20 years ago. But it's been about 20 years. Hard to retain stuff you don't even look at for so long. :)

I could have SBBSecho check the "KILLSENT" flag and not delete the netmail message file (*.msg) after packing in that case, but then it becomes kind of redundant with the -d option. I don't have strong feelings about it either way.

mailers as I hated BSO-style stuff back way back when. InterMail was
my demon of choice, versus FrontDoor, though. I don't even know what
D'Bridge uses, but with D'Bridge 4.0 coming to Linux sometime, I'll be
finding out. :)

I used all of the above. My recollection is D'bridge is also an attach-style mailer.

Hmmm. I don't really know. Though I do know exactly whom to ask, via FidoNet! :D Since he's announced D'Bridge 4.0 will be available for Linux. Honestly, I hated D'Bridge back in the day. But today, if it's at least attach-style like you say, I'm looking even more forward to it. heh

He "announced" D'Bridge 4.0 (initially he claimed to be writing it in Java) years ago. So I wouldn't hold your breath.

So, exactly as I said earlier. Based on this, it's "sent" as soon as
it's packed, because it's been processed, rather than handled by the
mailer.

That's not how that attribute flag is defined in the FTSC specs, but if it makes you happy, I guess that's what matters.

It does, actually, make me happy that is. One little thing allowing half my netmail to be available in a cross-platform usable format (OPUS).

What's the chances of getting sbbsecho's netmail /import/ to drop a OPUS .msg file down, at least if -d is set in sbbsecho? :)

Slim. I don't know why the "don't delete netmail" option would cause SBBSecho to create files it doesn't create otherwise. That logic seems backwards to me. In any case, it's no small change and nobody else has asked for it, so I think there are many higher priorities.

digital man

Synchronet "Real Fact" #65:
Synchronet was conceived of and mostly developed in southern California.
Norco, CA WX: 78.8øF, 62.0% humidity, 10 mph ESE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Hello Psi-Jack,

On 22 Jul 15 20:55, Psi-Jack wrote to Digital Man:

In times that I'm actually going to be involved with that, keeping a record of my netmail I sent with that token is a bit important, cause
I can verify and /see/ that record of it. Honestly I don't know why Synchronet treats NetMail (E-Mail too IIRC), with such a disregard for keeping a copy of what was sent on record until I choose to delete it. Local mail, no problem. I send someone on my BBS an private email, I
can see that and later delete it, or let the system clean it up when expiration time comes. NetMail, Internet E-Mail, or QWKNet Mail
(maybe the latter too, not sure?) Once posted, it's gone forever.

That's the overall "issue" I'm trying to solve. And IF anyone else
here agrees, I'd encourage to speak up, too. :)

I can speak up. I've never actually used it this way before. As I've told you, I setup Golded+ with Synchronet message bases and caught more oddities than I cared to deal with. So kudos to you for trying to get them fixed. This probably
isn't the fault of Rob as much it is the Golded+ developers that added support reading the msgs.cnf file but never extended anything else into Synchronet's abiltiies. But I digress.

So seeing your late requests has sparked an interest, and most have validity, to be honest. In this case, I agree fully, BUT I think since you're disabling sbbsecho completely from importing or dealing with netmails at all, there should be some way to handle netmails that have already been read, replied to, sent, etc. I don't want thousands of old netmails stored in my netmail directory. Would that then be on the Golded+ or Binkd maintainers to add an option to deal with it?

Basically, you're cutting sbbsecho out of the mix completely. Which is fine, because you want other programs to be able to handle it. I'm unsure if those programs will handle it after that. You can throw a kill/sent attribute on a netmail in Golded+ but, will binkd do it?

What's the chances of getting sbbsecho's netmail /import/ to drop a
OPUS .msg file down, at least if -d is set in sbbsecho? :)

If -d is set, wouldn't it NOT import the message and leave it in it's original form (which would be .msg anyways)?

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20150715
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Re: Re: sbbsecho and -d
By: Accession to Psi-Jack on Thu Jul 23 2015 05:30 pm

I can speak up. I've never actually used it this way before. As I've told you, I setup Golded+ with Synchronet message bases and caught more oddities than I cared to deal with. So kudos to you for trying to get them fixed. This probably isn't the fault of Rob as much it is the Golded+ developers that added support reading the msgs.cnf file but never extended anything else into Synchronet's abiltiies. But I digress.

So seeing your late requests has sparked an interest, and most have validity, to be honest. In this case, I agree fully, BUT I think since you're disabling sbbsecho completely from importing or dealing with netmails at all, there should be some way to handle netmails that have already been read, replied to, sent, etc. I don't want thousands of old netmails stored in my netmail directory. Would that then be on the Golded+ or Binkd maintainers to add an option to deal with it?

Basically, you're cutting sbbsecho out of the mix completely. Which is fine, because you want other programs to be able to handle it. I'm unsure if those programs will handle it after that. You can throw a kill/sent attribute on a netmail in Golded+ but, will binkd do it?

I'll correct you here. :)

Synchronet doesn't *post* netmail to it's mail.shd, instead it directly writes a *.msg OPUS style message in the configured netmail directory. sbbsecho would pick this up, and for BSO style mailers, would pack and delete it. Simple as that.

sbbsecho had the option, -d, to not do the deleting part, however that spawned a problem where it would repeatedly pack and send it every time because it had no idea it was already sent. The latest code revision that DM's made resolved this issue.

sbbsecho for *inbound* mail, directly reads the PKTs in the mailer's inbound directories and directly imports them into the mail.shd, completely skipping the *.msg OPUS netmail directory. I configured my GoldEd+ to read the mail.shd message base, but it's not without it's own problems. Since mail.shd contains BBS Private Mail, Internet E-Mail, and *received* NetMail, and for /all/ users not just the sysop, this causes some annoyance with GoldEd+ still, bugs in GoldEd's side causing it to crash on certain types of content.

This is why I am wanting to try to get NetMail handled externally more completely so this issue can be avoided more, like segfaulting external mail clients <G>, and not having to cross-post my message from Synchronet's mail to netmail for replying while using said external mail clients. At least until Synchronet can fully support FTN more completely that is. :) Once that happends, GoldEd+ itself will be a thing of the past more easily.

What's the chances of getting sbbsecho's netmail /import/ to drop a
OPUS .msg file down, at least if -d is set in sbbsecho? :)

If -d is set, wouldn't it NOT import the message and leave it in it's original form (which would be .msg anyways)?

Reverse of that. ;) -d just prevents the deletion of *sent* mail. sbbsecho, during importing netmail, I believe ignores the netmail directory entirely.

)))[Psi-Jack -//- Decker]

---
þ Synchronet þ Decker's Heaven -//- bbs.deckersheaven.com

Re: Re: sbbsecho and -d
By: Psi-Jack to Accession on Thu Jul 23 2015 07:49 pm

If -d is set, wouldn't it NOT import the message and leave it in it's original form (which would be .msg anyways)?

Reverse of that. ;) -d just prevents the deletion of *sent* mail. sbbsecho, during importing netmail, I believe ignores the netmail directory entirely.

Not true. If you're running a FD/attach-style mailer, then you need SBBSecho to
import your .msg files (from the netmail directory) and it'll do that happily.

digital man

Synchronet "Real Fact" #69:
Rob Swindell was interviewed for Jason Scott's BBS Documentary in July of 2002. Norco, CA WX: 80.7øF, 59.0% humidity, 9 mph S wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Re: sbbsecho and -d
By: Digital Man to Psi-Jack on Thu Jul 23 2015 06:17 pm

If -d is set, wouldn't it NOT import the message and leave it in
it's original form (which would be .msg anyways)?

Reverse of that. ;) -d just prevents the deletion of *sent* mail.
sbbsecho, during importing netmail, I believe ignores the netmail
directory entirely.

Not true. If you're running a FD/attach-style mailer, then you need SBBSecho to import your .msg files (from the netmail directory) and it'll do that happily.

Yes, but in BSO/FLO mode, it doesn't even look at that, is what I was saying. Course, that is a guess admittedly, but it's what it seems. That's also somewhat normal too, for tossers/packers to ignore the netmail directory for BSO/FLO because usually the BBS directly supports some method of importing/reading those messages should they exist.

)))[Psi-Jack -//- Decker]

---
þ Synchronet þ Decker's Heaven -//- bbs.deckersheaven.com