Hello g00r00,

On 06 Sep 14 12:27, g00r00 wrote to Avon:

 gr> BINKP has an unsecure inbound directory, where all files received from
 gr> an unknown source are saved.  Then there is an option in MUTIL to toss
 gr> unsecured packets and a second option to process unsecure TIC files.
 gr> If these are on, it fully processes them as if they were secure.

 gr> However, as AD recommended, it should never toss echomail or TIC; only
 gr> netmail for the automatic unsecure.  So this leaves me with two
 gr> options:

 gr> 1) Add an option to say "only toss netmail" or
 gr> 2) Remove the ability to process unsecure TIC/echomail all together.

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

 gr> Tossing the ONLY netmail from unsecure but keeping the echomail is a
 gr> challenge, because then Mystic would have to completely rebuild all of
 gr> the packets that come in so that they no longer contain the Netmail
 gr> messages that have already been processed.

 gr> I wonder how tossers handle this and what options they have today?

Very good point. Then again, quite a few (except maybe D'Bridge) mail/file 
tossers are completely separate from each other as well. I do know Htick has a 
"toss bad tics" command line option, but I don't think that has
anything to do 
with unsecure, just TIC files that weren't processed correctly the first time 
and moved to the bad folder.

HPT also has an option to toss mail from the BAD area, but I don't see anything
 
in regards to the unsecure folder. That being said, it would seem as though 
both of those leave it completely up to the sysop to move the contents of the 
unsecure inbound over to the secure inbound manually, which then they can 
process it.

That being said, once it's processed, it would probably end up in the BAD 
folder anyways, because if it was unsecure, it was probably not from a defined 
link, unless you were connecting someone new and they didn't have the proper 
authorization via the mailer.

I'm not completely sure with where to go with this. It would be *nice* 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 echomail/tics stayed in the unsecure folder 
for manual processing.. it would be a pain in the ass to search all echomail 
bundles/packets for any netmail that may be in them. :(

It may just be better to leave it as you have it, and let the sysop do any of 
it manually. If other tossers aren't doing it I'm sure it's probably for the 
same reasons you've already covered. That would give the sysop a chance to (if 
they were so inclined) to break apart any bundles to see what the contents are 
(netmail or echomail) before making the decision to process it.

Heh. Thanks for making me think it over, too! :)

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20130910
 þ Synchronet þ thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)