file mailing toolkit(fmtk)

this program is a file sending program configurable through a toml configuration file. its primary method of file sending is smtp, but is also compatible with local folder routing in case compatibility with cloud services like dropbox or onedrive, or other non mail workflows is needed.

warning for production usage

this software should currently not be used in any sencitive context where breakage would cause problems. it is relyable and does not offen break, but updates ar not garanteed and only username/password authentication is currently supported.

usage

with that out of the way, the usage of this software. the configuration file is named config.toml and should contain the following, for more details see src/config.rs at least one, but optionally more backend configuration entrys. and at least one, but optionally more directory entries(why ar you using this tool if you only have one directory to manage anyway) an example configuration would look something like this

[backends.mail]
type = "smtp"
server = "mymail.host
port = "587"
from = "some.person@mymail.host"
subject = "I dont know"
body = """multiline body
why?"""
[backends.mail.login]
user = "some.person@mymail.host"
password = "pleasedontstealmypassword"
[[directory]]
name = "my_stuff"
path = "/path/to/the/directory"
to = "another.person@someother.host"
backend = "mail"
bundle = true
mode = "move"
move_path = "/path/to/file/archive"

what was that?

that was a configuration file. but to be somewhat less fun and way more helpful: this configuration looks a little confusing at first, but it really isnt. so for the first line, [backends.mail] backends is the thing you ar configuring, in this case that is a backend. and mail is the name you give it. type = "smtp" type is the type of backend and smtp is well, the backend to use now this is where things could be confusing, but basically. what comes after the backend in the first line is the name you give it, an id. and the type is what type of backend it is. now, with that out of the way the rest of the block after the type = line is the type spesific configuration parameters, in this case the ones for smtp. the ones for local is only the path = "/path/to/destination" line. now for the directory configuration. most things in here ar self explanatory. but i will try to explain the others. name = "my_stuff" is just the name you give the directory, unlike the backends id this is not used anywhere, just for the filename of the zip bundle = true. this is a line that needs a little more explanation, basically. this determines if the files should be compressed in to a zip file before being sent. if false, they ar attached individually. or in the case of the local backend, which probably should not have been added transfered directly mode = "move" this is an other line that can be slightly confusing, there ar 3 modes, keep move and delete. they determine what happens to the file after being processed by the backend note, this modifys the unprocessed, not bundled or renamed files. keep keeps them in the same directory, do not worry. they dont get sent again the next time, mainly for integration with other tools. then there is delete, i dont know why you would use it. it could be useful for efemeral files, things that you want to send and not keep. but i personally never use it. then there is move, which if used, requires a second line. move_path = "/path/to/post/process/destination" to select where the files should be moved

why the local backend overlap

answer, dont know. but a more expanded apon answer is that i added it as mainly a test for the new multi backend refactor, and to adapt to changing requirements while minimizing the change to my workflow

why use fmtk

the answer is that you probably shouldnt, this was a tool that i wrote for my own usage and still use. but if you want to automatically email files then move them to an other directory or keep or delete them, this is an automated and somewhat easy way to do it at a large scale.

project future

it will keep getting maintained, as i personally depend on it, tho the addition of new features or interaction with pull requests / issues is not garanteed. some upgrades ar planned, like better authentication support and configurable tls, tho this only applys to the smtp backend

why is this readme so bad?

because well really, i dont intend for this project to get any attention, if it does. cool, i might update the readme. but this is mainly a tool for my own use, that i made available for others just in case something like it is needed by anyone else and it is not a professional tool, so why make that impression with the readme.