New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
In summary:
Funny how that is the same "never" refrain crops up for all sorts of innovations before they become widespread. My point remains that you already do know that spam is a solved problem. You simply are (unhappily?) using a solution that works at a late stage in the process (either filtering the messages or blocking the server). I prefer to solve it at the earliest possible stage I can think of, thereby (happily) avoiding the use of all those resources.
I still don't see any reason for all the drama that ensued.
Spam is such a problem that I've actually migrated from using a personal address that I've had for 20 years to gmail, because no matter how I setup my rules and filters- it still gets through.
I don't doubt you do, but it's from a very narrow perspective. I maintain that how spammers get email address is something that you should have an interest in, because it directly influences all the downstream activity you have to deal with.
Everything is hard for a new admin. A basic email server is not harder to maintain than a basic web server.
I know. That's why I said that offering better tools would help them help you. Yes, it can be convoluted to use disposable emails without a turnkey solution. But until the customer gets some sense of the (simplified) alternatives, there's no way to know for sure what they'll prefer to use.
But, keep in mind, that's just because they don't really care about how the solution works. They just want a clean-ish inbox. They don't have any concern about the volumes that get filtered unless they have to go looking for a false positive that ends up in their spam folder. And they have zero knowledge about the number of servers that get blocked completely.
Someone running their own server, the initial topic of this thread, is an entirely different situation, though. That doesn't necessarily require all the machinery you're throwing at the problem. And it can do a better job of actually stopping spam, since an invalid email address means the message never even leaves the spammer's server. It's a win for all the good guys, not something that should be harshly mocked.
Yes it is.
apt-get install lamp-server^
or easier:
apt-get install apache2
Setting up a functional mail server is significantly more steps than that. Installing a web server just works, instantly. Installing a mail server doesn't just work, instantly, or anything close to it. You have to ensure FQDN as hostname or at the least that the MTA declares a valid FQDN via HELO and also that PTR is set, and that fcRDNS checks pass. Those are basic bare minimum requirements and WAY more than required to get a web server off the ground. That's assuming just SMTP is the requirement, otherwise it gets even more complicated.
It's not that hard, but let's not lie about it's simplicity. It's not sysadmin 101, put it that way. It's definitely not course 1 material. Web server definitely is.
"simple outbound email" (assuming that forwarding is good enough): nullmailer, but there are plenty others.
"Spam": Yep, that's the real issue, that's where the meat is nowadays. smtp, pop3 is easy to do, either by canned stuff like postfix or by hacking up something with python or what have you.
Spam, however, is still a problem, particularly when one includes all those cases of "I had to given them an email address and now they send me shit". Worse even when, as I saw a couple of times now, "they" also send an inportant service related email once in a while so that simply deleting everything from them isn't good enough (which is why they do it, those assholes).
I have done some work on a modern email server with the main feature of a "spam-wall" but unfortunately it has become a low-prio side project. I'd be my first user.
Forgive me for further hijacking, but all of the talk about spam made me wonder; @Jarland do you all do anything for automatically monitoring outbound deliverability (i.e. making sure Gmail isn't just randomly putting stuff from your MTA into spam)? I've been thinking about how I might build a tool (maybe something already exists) to check to make sure a user with ${MAJOR_EMAIL_PROVIDER} actually gets your emails. I could also see this potentially being a trade secret.
Not particularly, but I've not had an issue with it unless the sender's domain itself triggered a content filter (which can't really be helped). It's really hard to monitor such a thing from a significant perspective since it's going to vary based on sending domain and content as well.
emails were a mistake
I'v solved similar task with docker-mailserver. Launched it in a hour. All you need to change docker-compose.yml file for you needs. Attach spf/dkim/dnssec/ptr to your sending domain. Scored 9 at mail-tester.com
I'd like to see more reviews about it
What could have been improved?
Or you can do like I did and I was wanting to see more reviews but decided I would be better off firing up a test server for a 30-90 day test rather than trust somebody's review of it. After 60 days, I migrated 5 Zimbra servers over to Mailcow (paying customers included) and never touched Zimbra ever again.
My ip is in one of black lists after previous owner. Even dont bother with that.
I'v tested several solutions iredmail, mailcow, poste.io, mail-in-a-Box and serveral more. Mailcow is quite heavy. When it dockerized, mailcow starts 11 containers.
that's a nice review already; did you use the dockerized version?
I see; I'd move to a clean ip - for non-vanity mail domains at least. Anyway you confirm that you got an otherwise perfect scoring OOTB
Not a fan of docker to be honest, but it's so massively deployed and "convenient" that resistance is futile I guess
No. I never caught on the Docker thing like most "buzz" things the cool kids do. Installed straight on a OpenVZ VPS on my OVH dedicated server. Since there's 5 Mailcow VMs, I manage blocking spamming IP networks and adding in domains to fuglu's action rules through ansible rather than login to repeat commands across 5 servers
I'm sure you know that's not true. Yes, just having something generically sitting there and accepting traffic on port 80 can be easily done, but that's just as easy to do for a mail server. To do it "right" for either is likely going to require setting up virtual host configurations so that you respond as something other than just an IP address. How easy or hard that is depends on your admin skills and the server of choice.
And on the web side people are likely going to install and configure a stack of some kind (often WordPress, unfortunately) and then be forced to maintain a crapload of questionable plugins and deal with other vulnerabilities that can seriously screw up your server.
Mail just needs to pass messages around. The biggest worry is external deliverability, not making sure the server doesn't turn you into part of a botnet.
Right back at ya! :-)
Nah. A working web server only needs to do two things: Take requests and return data that can be used for display in a web browser.
A working MTA must do one thing: Send email
If the sever is not configured just right, you can't send email because it gets rejected. If a web server is merely installed, it immediately meets the criteria for a running web server. It functions right out of the box.
An MTA, immediately after installation with no further thought or work done, will not perform its basic core function, not because of it but because of the rest of the internet. A web server will. It stands alone and doesn't matter what other servers think about it.
I don't know why you continually insist on spreading misinformation.
Docker apps tend to confuse me with "where the heck do I edit stuff" but the mailcow setup is reasonable. Pretty much runs out of the folder you extract it to.
Now now, boys. We don't need to get into the intricacies of MTAs vs GETting, HEAD, POSTing and so forth, do we?
Please. You know very well that probably less that 5% of web sites are set up to work like that. My blog actually is, but I had to go out of my way build it to work without a server-side app processing requests (I had formerly used Drupal).
Nonsense. Probably 80% of installed MTAs do nothing other than handle local emails. Hell, that's exactly what the default install of sendmail was doing on my system until I decided to try configuring it as a proper MX (failed, gave exim a shot next and it worked swimmingly).
I don't know why you think you're going to convince any readers that running a modern web server is a trivial affair. People here probably have the most experience in setting up web services, whereas you might actually have a shot at convincing them that setting up a mail server is complex if they've never done it before and you spray them with a series of acronyms again. I'll just say what I normally say: people should just give it a shot as a learning experience. They can then decide for themselves who favors misinformation.
Jesus you too just grudgefuck already.
No, this is my fetish:
Pip pip, Honey Nut Cheerios!
That horse DOES need configuration, because I don't think it's gonna be delivering much without SOME effort.
Is there some features you miss in mailcow coming from zimbra
I don't miss Zimbra one bit. Or "Zimbloat"
You don't like the overhead of 2GB memory and 1 CPU core per 1/2 user?
Hi guys
Sorry for my late reply
I chose sendmail and It works so far
thank you all for your recommendation
Nowadays, the "lightness" in terms of MBs of a mail server (and by "mail server" I mean an MTA) is probably not so crucial. Instead, ease-of-use, configurability, and documentation are more important.
I find that sendmail is a good choice even if there are many who would disagree (largely based on painful memories of sendmail in the 90s). :-)