spamgourmet evolution - countermeasures to increasing blacklisting

vasile-gh commented 2 years ago

The reality is that more and more lists flag spamgourmet as "disposable" although its intent here is not really that. Because these lists rely on the mx records to identify spamgourmet domains we cannot hide "private" domains - I have a private one and it's just as unusable as the known ones, because my MX must point to spamgourmet.

I think in the long run spamgourmet is going to be less and less usable so I have been thinking of what could we do about it.

My proposal would be to:

"dockerize" spamgourmet and provide simple step by step instructions on how to install and configure the domain so it can work - this would include private certificate-based access to the spamgourmet clone site so only the owner and people designated by him can even see it's a spamgourmet clone
investigate enabling ARC for the clones - this would make mail delivery a lot more reliable
support options would need to be discussed, but I guess whoever is able to clone spamgourmet should be able to live without their hand being held...

josiah-hamilton commented 2 years ago

Dockerizing would be good I have been anxious to port code over because my dad has so much testing code in the production directory.

I have struggled personally to get companies to create accounts but I generally call them and an agent makes the account for me anyway.

Sorry I pressed the wrong button. I'll draft outside of github and post something better thought out.

josiah-hamilton commented 2 years ago

Dockerizing would be good. What is kind of strange is that running a stable buster instance running this all has been free of all the high profile linux vulnerabilities (j4log, pwnkit, dirty pipe, etc), and it needed an exim patch some time back. But I understand we can't just be sitting ducks and need to move on before other ones become high profile. However, I have been anxious to port code over because my dad has so much testing code in the production directory, and there are still a few features I haven't quite mapped out like adding extra domains. So if we dockerize, we can make it easier to deploy. The last feature that is available but not mapped to the web instance is alternative recipients which is a by-disposable sort of thing. The one we shouldn't port to the public repo is the DoS mitigation.

I have struggled personally to get some companies to create accounts just depending on who manages their "spam & bots" service, but I can generally call them and an agent makes the account for me with the preferred email anyway. It seems like the future is becoming either interacting with employees or using cloudflare email proxy service with a catch all and maybe putting something like spamgourmet behind it.

mikedlr commented 2 years ago

@josiah-hamilton great to hear from you. There was some fear that something bad had happened. I think I'd like to get a clear way to have direct contact - could you perhaps connect with me on LinkedIn so we could exchange phone numbers?

The "testing code in the production directory" sounds incredibly valuable. I think we need to get an agreed and trusted group of people who can view at least some of the stuff on the production server which isn't published and can go through it making as public as it safely can be. There's some discussion already in issue 19 where I think some comment about what would be helpful for you in future and how much you can engage would be good.

Dockerization - I think this is the only way to go practically - we need to have a quite specific development and runtime environment available. I've done this before and had started to work on it a bit but not sure about having enough time given the state of the public code. It might be good to have a live video call for a mob session with a bunch of us and have a start at doing that?

@eegeeZA are you around and would you join something like that

eegeeZA commented 2 years ago

I have tried with limited success having some account created too. I remember being told by one website's support that because block-disposable-email.com listed spamgourmet as a disposable provider, they would not accept my email. I opted to using my ISPs email address and forwarding that to my main email as a workaround.

@mikedlr I'm on board for going the Docker approach. If we can get the code running there, it will be a much smaller hurdle for others to run the code. Reached out on LinkedIn for if you manage to get that mob session going.

josiah-hamilton commented 2 years ago

@josiah-hamilton great to hear from you. There was some fear that something bad had happened. I think I'd like to get a clear way to have direct contact - could you perhaps connect with me on LinkedIn so we could exchange phone numbers?

The "testing code in the production directory" sounds incredibly valuable. I think we need to get an agreed and trusted group of people who can view at least some of the stuff on the production server which isn't published and can go through it making as public as it safely can be. There's some discussion already in issue 19 where I think some comment about what would be helpful for you in future and how much you can engage would be good.

Dockerization - I think this is the only way to go practically - we need to have a quite specific development and runtime environment available. I've done this before and had started to work on it a bit but not sure about having enough time given the state of the public code. It might be good to have a live video call for a mob session with a bunch of us and have a start at doing that?

@eegeeZA are you around and would you join something like that

Mike, I wasn't able to find you on linked-in, so I sent you contact info on bbs. Would you please check that so we can open communications?

spamgourmet / spamgourmet

spamgourmet evolution - countermeasures to increasing blacklisting #20