On Mon, Apr 15, 2024 at 01:48:53PM +, Michael Grant via users wrote:
> > I don't like any daemon connecting to my mail storage. Can you imagine if
> > your solution gets hacked, how much data would be compromised? I prefer
> > messages being scanned/marked before stored. I wonder if this is even gdpr
> > compliant, because you can access private data constantly.
> First, for people like yourself, you would want to run such a daemon
> yourself on your own infrastructure, hence why I am thinking of this could
> be useful to other people as open source.
>
> Second, there are plenty of people who don't run their own email, as in,
> gmail users, that entrust their email to google. Though GDPR probably has
> something to say about such a service, I doubt it would be impossible under
> GDPR, especially EU users using a suitable EU server and whatever rules
> necessary were followed.
Not impossible, no. But there are many things needed to implement
GDPR correctly, overhead is huge, and the fines are draconian, so I
wouldn't advise it unless you're willing to choose dealing with all
that as your main life career path. Not to mention that Google
themselves will likely block you (in better case) or sue you for ToS
violations before it could become financially viable model.
> > Why not just forward messages? Register a domain put some mx servers in
> > front of gmails mx. I recently was testing with such relay/forward, works
> > perfectly, I am only changing the envelope nothing else. DKIM, spf
> > everyting perfectly working.
> >
> I'd be interested to know if anyone runs spamassassin forwarding from gmail
> back into gmail, how does this work? How to get it so mail isn't in a loop?
> You can't do what I'm talking about just by forwarding. More below on that.
I haven't really touched gmail in decade or few, but back then IIRC
it was relatively easy: you could choose to forward mail only when
some criteria was met (e.g. using email+extens...@gmail.com, or some
header etc), instead of forwarding everything. And even if gmail no
longer supports that, you could implement loop handling on the other
side alone (just with a little more overhead)
> > So for the whole of Europe you need data processing agreement for accessing
> > the mail storage as a 3rd party.
> Probably, yes. Is it any different with a mail server that uses a back end
> scanner as a service? I know there are several such services for corporate
> email that work with a google workspace account that allows you to modify
> the mail routing which you can't do with a free gmail account.
Well you'd likely need to hire a bunch of lawyers and study
requirements of GDPR for some months to model how it behaves in
corporate environment before engaging in risk assessment and building
your business model on top of those results.
> You can argue that it's really crazy giving access to your whole mailbox to
> your email provider too.
It *is* crazy. That's why all the cool kids ain't doing it for decades now.
They run their own VPS with SA, or install a FreedomBox or something. :)
Definitely don't depend on @gmail.com whatever !
> I guess I don't see the difference here. Your mail service provider
> could be broken into as well.
Sure, as can Gmail.. The difference is in statistics: even if such
service was technically and financially[1] as secure as Gmail (which
may be debatable), by the simple fact that your mail is now routed
through 2 SPOFs instead of just 1 SPOF means your chance of problems
has increased by at least 100% (i.e. doubled).
> I'm just wondering if there's enough interest in this to do the work to make
> it open source. If there were a lot of people mailing me saying "Yes! I've
> been looking for something like this but I don't want to run it myself!",
> then I'd consider making it into a service, as well as probably open
> sourcing it. Thing is, such a service has to minimally viable. So far,
> you're the only response I've seen to this and your response appears to be
> overwhelmingly negative.
Here is my advice: don't overthink it in advance. Instead:
- Pick a nice open copyleft FOSS license (e.g. AGPLv3+)
- write a dozen or so lines of most basic requirements and installation
instructions in README
- publish whatever you have at the moment out on some source-hosting platform
out there
(can't really recommend any really open one; you can self-host, or choose one
of popular
ones, not really critical at this point)
- mention it at few related places
If people find it interesting, you'll note it in a number of issues,
feature requests, etc. As the demand grows, you can improve it.
If not, hey, you've wasted barely no effort, and did a good deed, so
it is a karma net positive in life, eh?
If it however turns out that it eventually becomes so popular so you
must choose between your day job and maintaining it, then you might
consider incorporating and launching it as a service. But not before.
> matter how
