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.synch

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.

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.s

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

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

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