> In contrast, Spilled.ink fetches all related images on
> server as soon as the email is received and encodes them
> into the message. This hides your location, and whether or
> not you opened the message, from trackers.
Wouldn't this expose the validity of the email address to every embedded tracker, since it's going to hit the tracking URLs to load the tracking images for embedding into the email?
The point of the feature though is that the trackers can no longer provide meaningful insight beyond what the lack of a bounce provides, since the server will always fetch whether the email is opened or not.
After recently learning Mutt and falling in love with its macros and tag handling I was thinking about implementing a GTD flow based on a local email server and use mutt as the client.
You might be interested in https://github.com/zedshaw/lamson
It's super old (died when python 2 was still the king) but probably more suited for making programmatic mail applications
There is an active lamson fork https://github.com/moggers87/salmon that retains the original GPL license and supports current Python 2.x and 3.x versions.
Difficult to search for, so I'll ask on the chance that you know: I see .vel files in that repository. Do you know anything about what language or format that is?
It seems to me, that rather than using the maildir or mbox formats, they're utilising sqlite for the backend, which, depending on how the schema ends up, may be much faster.
sqlite is not a proper choice for a service like this, something like Postgres could actually provide a proper DBE that could net some performance benefits.
People running their own email servers probably don't need higher performance than what SQLite can offer. Meanwhile the maintenance overhead of an SQLite-based setup is almost nil, and migrations & backups are trivial — two big benefits for people running their own email servers.-
To me this seems ideal - you can already get IMAP-in-Postgres through lots of mail servers, it just takes more work to set up. Whereas sqlite is a strict upgrade compared to using mbox or maildir for people using a local filesystem (not NFS) while still requiring no setup.
The validity is already known since most email servers will send a bounce if the address is not valid.
True, though it would still be considered as 'read' by the trackers.
The point of the feature though is that the trackers can no longer provide meaningful insight beyond what the lack of a bounce provides, since the server will always fetch whether the email is opened or not.
This is interesting.
After recently learning Mutt and falling in love with its macros and tag handling I was thinking about implementing a GTD flow based on a local email server and use mutt as the client.
This project might serve well for prototyping
You might be interested in https://github.com/zedshaw/lamson It's super old (died when python 2 was still the king) but probably more suited for making programmatic mail applications
There is an active lamson fork https://github.com/moggers87/salmon that retains the original GPL license and supports current Python 2.x and 3.x versions.
Difficult to search for, so I'll ask on the chance that you know: I see .vel files in that repository. Do you know anything about what language or format that is?
https://pypi.org/project/vellum/ https://launchpad.net/vellum
They look like configure files for a python build script:
https://github.com/zedshaw/vellum
Could do with an explanation of why this is distinctive ..
It seems to me, that rather than using the maildir or mbox formats, they're utilising sqlite for the backend, which, depending on how the schema ends up, may be much faster.
sqlite is not a proper choice for a service like this, something like Postgres could actually provide a proper DBE that could net some performance benefits.
People running their own email servers probably don't need higher performance than what SQLite can offer. Meanwhile the maintenance overhead of an SQLite-based setup is almost nil, and migrations & backups are trivial — two big benefits for people running their own email servers.-
Migrations and backups are trivial with Postgres as well.
To me this seems ideal - you can already get IMAP-in-Postgres through lots of mail servers, it just takes more work to set up. Whereas sqlite is a strict upgrade compared to using mbox or maildir for people using a local filesystem (not NFS) while still requiring no setup.
You shouldn't run your own mail if you can't install postgres.
The website is actually quite descriptive of what it does. Seems like a nice little service/self-hosted email product.