If I want my system to accept crash mail from any system that wants to send it to me... so that's crash netmail sent directly to my agoranet or fidonet address.. how do I set my Mystic binkp up to do this?
I have a nagging feeling I can't as I need to state echomail nodes explicitly to get bink onnections working - right?
If I was using binkd I think the issue goes away as it could be counted
as an unsecure connection at least?
Any thoughts appreciated.
I don't think that receiving connections is the problem. I think that sending is the problem. The issue with crash mail is that the sending nodes' mailer needs to know how to connect to you. I would think that reading the address from the nodelist would work, but I don't know of a mailer that will do that. I know that when I ran binkd, I could create a binkd.list from the nodelist, and use it as an include file to the binkd.conf file.
If I want my system to accept crash mail from any system that wants to send it to me... so that's crash netmail sent directly to my agoranet
or fidonet address.. how do I set my Mystic binkp up to do this?
I have a nagging feeling I can't as I need to state echomail nodes explicitly to get bink onnections working - right?
If I was using binkd I think the issue goes away as it could be
counted as an unsecure connection at least?
Any thoughts appreciated.
I don't think that receiving connections is the problem. I think that sending is the problem. The issue with crash mail is that the sending nodes' mailer needs to know how to connect to you. I would think that reading the address from the nodelist would work, but I don't know of
a mailer that will do that. I know that when I ran binkd, I could
create a binkd.list from the nodelist, and use it as an include file
to the binkd.conf file.
With mystic, that is another matter.
Receiving was a problem for me the other day. A Z2 address could not
send me anything until I set him up as an echonode in my system :-(
Receiving was a problem for me the other day. A Z2 address could not
send me anything until I set him up as an echonode in my system :-(
That's because Mystic doesn't currently support connections with people not defined in your node configuration. It's probably on the top of the TODO list, though..
It's in the Message Base Settings, not individual links or the editor where we thought it may be. You'll see "Netmail Crash," "Netmail Hold"
and "Netmail KillSent". That's where you enable it.
Receiving was a problem for me the other day. A Z2 address could not send me anything until I set him up as an echonode in my system :-(
That's because Mystic doesn't currently support connections with people not defined in your node configuration. It's probably on the top of the TODO list, though..
A52 has had the ability to receive (via BINKP) and toss unsecured files for a couple of months now; it was the first thing I added. Unfortunately, I haven't gotten around to getting A52 ready for release just yet.
I'm not sure if you remember but we had some dialog about this. A52 does already support unsecured receiving and inbound processing.
If you recall when I told you it was done, you suggested I changed it so that only unsecured netmail would be imported and everything else (TIC
and echomail) would be trashed.
I'm not sure if you remember but we had some dialog about this. A52
does already support unsecured receiving and inbound processing.
If you recall when I told you it was done, you suggested I changed it
so that only unsecured netmail would be imported and everything else
(TIC and echomail) would be trashed.
I need to go back and make those options before I can release A52.
I was also hoping to get my Pi going so I could release A52 for the Pi
too but I haven't had time to start on that yet either.
..this is for outgoing stuff from my board... so yep, thanks was aware
of those settings and they are all off. It's the inbound netmail from
an unknown system I want to be able to handle - so I can honour a CM
flag against my nodelist entry in FidoNet.
Yes I really hope so and this is exactly what I would like to be able
to do... if I used binkd I think I could as I could set up some sort
of unsecure directory but not with Mystic - yet :-)
By trashed do you mean chucked into a 'bad' dir for possible manual inspection and further manual processing? Better that than just
deleting it altogether I would have thought.
you hatch A52. So this feature would handle both netmail and other files sent to the BBS from an unknown connection?
I doubt Mystic supports this (yet?). But we just went through this the past couple days, when Psi-Jack was routing a Fidonet netmail through my system to Janis. I don't have Janis configured anywhere here on my
system, as I route through Ross. Well, his netmail went from my system directly to Janis anyways, because he had the "Netmail Crash" option set to yes.
Mystic should ignore that on newly arrived messages that are intransit to other systems... it should also strip it out of locally written messages being exported... not only the crash bit but also the direct bit and i'm thinking maybe another one or two...
BINKP has an unsecure inbound directory, where all files received from
an unknown source are saved. Then there is an option in MUTIL to toss unsecured packets and a second option to process unsecure TIC files.
If these are on, it fully processes them as if they were secure.
However, as AD recommended, it should never toss echomail or TIC; only netmail for the automatic unsecure. So this leaves me with two
options:
1) Add an option to say "only toss netmail" or
2) Remove the ability to process unsecure TIC/echomail all together.
Not sure which one to do, and I am open to suggestions.
Tossing the ONLY netmail from unsecure but keeping the echomail is a challenge, because then Mystic would have to completely rebuild all of
the packets that come in so that they no longer contain the Netmail messages that have already been processed.
I wonder how tossers handle this and what options they have today?
Mystic should ignore that on newly arrived messages that are intransit
to other systems... it should also strip it out of locally written messages being exported... not only the crash bit but also the direct
bit and i'm thinking maybe another one or two...
FWIW: this was a bug seen years ago with other software packages and
the solution in them was as above ;)
actually, tess didn't write the above... /i/ wrote it when she showed
it to me and let me have the keyboard... i should have waited until
she logged out and wrote it on my account later when i checked the
mail... ooops :redfaced:
My suggestion would be to only toss netmail, and leave the rest
untouched in the unsecure directory. All a sysop would need to do if
they wished to process that tic and file and/or echomail, would be to
move them to the secure inbound directory.
to be able to process any netmail. Just recently there were instances where netmail ended up in someone's unsecure folder, and they didn't
find it there for more than a week until someone mentioned sending something to that person. But like you said, if it's only that, and
Mystic should ignore that on newly arrived messages that are intransi to other systems... it should also strip it out of locally written messages being exported... not only the crash bit but also the direct bit and i'm thinking maybe another one or two...
Doesn't that kinda defeat the entire purpose of the crash and direct bits you're referring to?
Also, is there some kind of FTSC standard or proposal documented on this so I can refer it to the Synchronet developers?
1) Add an option to say "only toss netmail" or
2) Remove the ability to process unsecure TIC/echomail all together.
Not sure which one to do, and I am open to suggestions.
My suggestion would be to only toss netmail, and leave the rest
untouched in the unsecure directory. All a sysop would need to do if
they wished to process that tic and file and/or echomail, would be to
move them to the secure inbound directory.
My suggestion would be to only toss netmail, and leave the rest
untouched in the unsecure directory. All a sysop would need to do
if they wished to process that tic and file and/or echomail,
would be to move them to the secure inbound directory.
I support this, it's the best way forward IMHO.
to be able to process any netmail. Just recently there were
instances where netmail ended up in someone's unsecure folder,
and they didn't find it there for more than a week until someone
mentioned sending something to that person. But like you said, if
it's only that, and
This brings me to the other thing on my mind about all of this and
that's something I'd find useful. If MUTIL can be configured to
produce reports that could be auto posted to nominated message bases around these kinds of activity.
1. The following files were received today (secure files report)
2. The following files were received today (unsecure files report)
3. The following files failed to toss (.tic bad files report)
If we could link these reports to a template and then be able to
customise it and then inject the output to nominated message areas it would be cool. Then as a sysop I could see at a glance in a s255
message area if I had an issue to deal with... as like AD I have found .tic's in the bad dir that have failed to toss files hatched out only
by chance when looking into the dir weeks later.
Doesn't that kinda defeat the entire purpose of the crash and
direct bits you're referring to?
no because they only pertain to the system originating the netmail messages in question... no other system's routing settings should be overridden by my system's settings... consider POTS connections and i
drop off netmail on your system for delivery to a node in australia...
are you going to be happy when your phone bill comes in and you are
the one paying for a phone call to OZ instead of me? ;)
Also, is there some kind of FTSC standard or proposal documented
on this so I can refer it to the Synchronet developers?
not really... this comes from the "school of hard knocks" and lessons learned... this is also done when packing the mail... the local copy,
if one remains, still has those bits set plus the sent bit...
i might have something around here from historical development conversations concerning this... let me look for it... there's a lot
to dig through, though...
My suggestion would be to only toss netmail, and leave the rest
untouched in the unsecure directory. All a sysop would need to do
if they wished to process that tic and file and/or echomail,
would be to move them to the secure inbound directory.
exactly... that's what we do now...
also, don't worry about trying to rebuild the PKTs after tossing any netmails they may contain... i mean, sure, it would be OK to exactly duplicate the PKT right down to the name and timestamps but without
the netmail but it shouldn't be necessary as that netmail, when tossed
a second time, should appear as a dupe... this might also be a reason
why so many other systems pack netmail and echomail into separate
PKTs...
speaking of dupes, it would also be nice for messages in the BADMAIL
area to have an additional couple of hidden control lines added to
them stating what echotag they were destined for, what system they
arrived from and what dupe checking method was used to catch them...
this way we can move them to the proper area if we determine that they
are false positives or we can let the sending system know of a
possible problem...
On 09/06/14, tesoro said the following...
actually, tess didn't write the above... /i/ wrote it when she showed it to me and let me have the keyboard... i should have waited until she logged out and wrote it on my account later when i checked the mail... ooops :redfaced:
netmail but it shouldn't be necessary as that netmail, when tossed a second time, should appear as a dupe... this might also be a reason why
speaking of dupes, it would also be nice for messages in the BADMAIL
area to have an additional couple of hidden control lines added to them stating what echotag they were destined for, what system they arrived
from and what dupe checking method was used to catch them... this way we
netmail but it shouldn't be necessary as that netmail, when tossed a second time, should appear as a dupe... this might also be a reason w
This is a good point, thank you for pointing that out.
speaking of dupes, it would also be nice for messages in the BADMAIL area to have an additional couple of hidden control lines added to th stating what echotag they were destined for, what system they arrived from and what dupe checking method was used to catch them... this way
I actually already have that in my TODO list :) The idea being you can see the base, but also press one button to move it to the base it was supposed to be in (just in case they were incorrectly tossed there).
| Sysop: | Nelgin |
|---|---|
| Location: | Plano, TX |
| Users: | 579 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 24:51:17 |
| Calls: | 9,341 |
| Calls today: | 4 |
| Files: | 16,010 |
| D/L today: |
1 files (8K bytes) |
| Messages: | 1,050,531 |
| Posted today: | 6 |