My solution was to set up SMTP relaying based on the recipient domain. So nearly all my email can still be sent direct, but I have a list of domains that get routed through mailgun.com (or you could use SES or whatever).
More info here: https://github.com/docker-mailserver/docker-mailserver/issue...
This would be me. DO traffic is overwhelmingly hostile traffic. It's like Psychz or MCColo got massively scaled up.
OVH is a close 2nd. Amazon was a solid third, beginning in 2019. Not sure if they still are.
There was a time when I looked at sending in reports -
and a time when I asked someone in the wp plugin directory who had a detector-like plugin to have it spit out a chunk of fields that would be ready to fill in the amazon complaint form and to do a cidr lookup to port over to iptables.. but that never got made.
This was all made worse when maxmind went registration needed and ruined the most effective security plugin for wordpress I'd been depending on for years.
I've noticed an increase in the microsoft ips I'm blocking these days to.
for now I don't mind doing an ip lookup when I can block 64,000 ips or more at a time I find it's a solid win.
Is there anything I can do to get whitelisted? How can I contact you?
Not a huge deal if not, I've implemented the workaround already. But to be whitelisted after a chance meeting on HN would be a nice way to finish this story.
Most providers do not mandate a strong SSL only imap system.
Along with other similar caveats, do not depend on your mail system to keep your emails private.
If you want privacy, encrypt your emails yourself.
Also most people who selfhost their email usually do not encrypt data at rest. As its not the default norm. As such anyone having access to your disk can compromise you at anytime too (especially likely if you’re using a vps).
So, unless youre encrypting your emails yourself E2E. Assume you have no privacy. If you’re doing E2E, aws cannot decrypt your mails anyways.
Besides, metadata is probably already more significant than the message contents and encrypyion solves nilch there.
I imagine 99% of outgoing Amazon SES traffic is transactional or marketing email for various online services. I worry this could make my personal emails look more like spam to the big providers. Or maybe it works out fine.
This is in contrast to Microsoft which seems to rely mostly on IP reputation and trying to send from a new server is incredibly difficult as they (reasonably) treat unknown Digital Ocean IPs as likely spam but (unreasonably) don't allow a good domain reputation to override that.
Aws ses has this offer where for a few thousand emails per month, email sending is free.
The steps are this:
1- Signup for aws ses, once you do that they’ll put you in a sandbox environment
2- After that they’ll ask you a few questions on why you need it, just tell them its because you’re a growing startup who expects to send thousands of emails per month, (make sure to say this, they don’t crosscheck later, if you dont say something along the lines of this, they usually reject your application to avoid having to serve small customers who might not scale their business later. )
3- After you’re approved, they provide you with a mail relay api key, just take that api key and attach it to your postfix or other smtpd installation
I use docker-mailserver[0] which packages everything I need for my mailserver into a small container and was good to go, it consumes minimal resources too.
For me, i just had to add the ses relay api key to the config file of my docker-mailserver install and it was all setup.
However you can do the same with any provider that gives you an option to act as your email relay, I remember both aws ses and sendgrid provide this service, but I’m sure there are more niche businesses providing this too.
I have the same setup as you, relaying outbound mails through SES. I told exactly how I was going to use it and was accepted promptly. Maybe I just got lucky.
I'm having trouble parsing this. Are you talking about VINs?
Personally, I think the use of proof-of-work like methods can mitigate the problem by a large extent, making it computationally expensive to spam users. This was one of the original goals of what has now become the "blockchain" revolution. Is anyone aware of any projects that are still implementing similar (open) systems?
> When you need to explain to people why they can't send you that 100 MB video attachment which they sent to other people just fine but only your address is bouncing and why don't you fix your email already.
The maximum attachment size for Gmail is still conservative 25 MB and they basically dictate what is currently to be expected in terms of attachments going through.
According to this page the incoming limit "depends on several factors" and can be as high as 150MB.
> Remote Server returned '552-5.2.3 Your message exceeded Google's message size limits. Please visit 552-5.2.3 https://support.google.com/mail/?p=MaxSizeError to view our size 552 5.2.3 guidelines.
EDIT:
> When someone decides to run a persistent brute force attack from a botnet, eating up 100% of your CPU and you have no meaningful ways to block it.
postscreen? http://www.postfix.org/POSTSCREEN_README.html
BTW, there is soo much FUD in your comment, check http://www.postfix.org/ before claiming "someone will hack your email"
""" First of all, thank you for your interest in the Postfix project.
What is Postfix? It is Wietse Venema's mail server that started life at IBM research as an alternative to the widely-used Sendmail program. Now at Google, Wietse continues to support Postfix.
Postfix attempts to be fast, easy to administer, and secure. """
When I was in my twenties, I would have empathized with your point. I used to host my own web servers, but back then, my main priorities were curiosity, privacy and independence.
Not just that, I opened accounts for friends and family.
A decade later, I made all my hosting someone elses‘ problem, because I had different priorities.
There‘s nothing like the sound of a friend shouting in your ear because he trusted you with his mail address and he‘s running into weird errors. Or trying to get an important email delivered after a 10h crunch shift when you just want to bring your kids to bed instead.
I‘m thankful for all those learnings, but nowadays, I‘m old enough to just want mail to frickin work, that‘s why Google does it for me on a custom domain.
I spend approximately no time at all in maintaining my email infrastructure which I set up around ~10 years ago.
Of all the things I self-host and self-manage, my email server and related parts is the one which requires the least attention and ongoing work, by far. Set up postfix, it'll take some work initially, then it'll chug along forever.
If other email providers are blocking you, smarthost through an email provider.
If you're getting brute forced, learn how to set up and run blocklistd or fail2ban.
Not getting 100 meg attachments is an issue that other email providers have, not people who run their own servers. If your server doesn't have any free disk space, that's on you. If it does, then set confMAX_MESSAGE_SIZE to whatever you want.
If by "standard X" you're talking about SPF or DKIM, there are lots of tutorials.
If your email software is vulnerable because of issues with your distro, you're doing things wrong.
The point is if you can't, don't. If you don't want to think about issues like these, then you shouldn't be running servers, anyway, so you're definitely not the target audience.
If you can, then these things aren't issues.
What about updating OS/packages/CVE when on holiday? Note that many CVEs are usually sent only to top-tier providers.
As a sidenote: The two RCEs this year were enough for me to judge the quality of this software.
If a whois entry of the attacker's IP/domain can RCE your intrusion blocking software, I mean...really?
Can someone please explain what this means?
Ed: as sibling correctly notes, "smart hosting" specifically referes to setting your smtp server to relay via another (eg: Gmail) - eg exim or postfix allow setting a "smart host" so that rather than looking up the receiving smtp server, all mail is shunted to the smarthost to figure out.
Added: you might get good delivery to Gmail using Gmail smarthost (requiring you to have a Gmail account) - but you might need to use outlook.com as a smarthost to get good delivery to o365 accounts... Etc.
If you're really properly securing your mail server, it would likely be isolated behind a firewall and only have a LAN ip of some kind and utilize UUCP for transport to another LAN machine that does not have WAN access, and then, only allow POP3/IMAP access to machines in the LAN or connected to the LAN via VPN tunnel. Finally, you would want to setup a backup system of some kind for this machine to periodically backup via rsync when the inotify/fswatch file modification triggers.
Next, you'd have a separate SMTP machine. For things like critical deliverability, you can't rely on SMTP to 'retry' albeit it's how they are supposed to act, so it would make sense to have multiple SMTP machines across multiple different backbones in different physical locations with backup power and the like with different MX priorities set.
The initial configuration and running a mail server are incredibly easy.
It's running it securely that increases the difficulty on order of magnitude (because you essentially have to setup a proper security protocol across multiple machines (a network) - defense in depth).
That said, it's easily doable if you're already running complex infrastructure. Hopefully, you're getting paid for your time and costs for doing so.
If not, then I hope you need to rely upon the protection of needing a home-invasion warrant vs a simple-subpoena since a machine at your home can't really just be 'subpoenad' while a machine at some datacenter business can. This of course assumes you're even running the machine at home because if you're doing all this on some VM the value of doing so diminishes ever so quickly.
EDIT: Just to be clear, you can't simply rely on fail2ban and some other on-machine script / snort / daemon / kernel feature to protect you. There are bugs in software/systems and 0days are very real (as well as the market places for them).
Yes, if you choose to run a service it will need to be maintained, and occasional issues will come up.
If my custom media server or private photo site setup fails, it is not a big deal. But if I can’t login to a shopping site or my family can’t checkin to a flight because the two-factor auth email disappeared in to thin air, I am the “horrible IT person” who spoiled Christmas - end of story.
You can script checking those, but you'll have to re-implement it for each provider. And there are some that you can't; if I'm applying for a job, they're not going to give me an email account to test whether my stuff is deliverable.
HTTP services are absurdly easy to monitor in comparison.
A mailserver administrator is a sysadmin. Being a sysadmin is on the face of it unrewarding - nobody pats you on the back when everything is working normally. They only call you when there's a problem (and it's usually urgent, and sometimes critical, and they'd like to know who to blame). So if you run a mailserver with users, it starts to become a people job, and things begin to matter.
People certainly rely on email to a greater extent than other services - even mobile. I can order goods online without surrendering my mobile number, but I always have to provide an email address before I can complete the order.
But I've still enjoyed administering mailservers. Perhaps I liked the slight paranoia induced by trying to reconcile the boss's demands for functionality with his demands for security.
1. I have tested both sides running their own SMTP on small, i.e., less than 100, peer-to-peer overlay network and it works. "OTT email". Interesting question for the reader is how does spam enter this system. If the spammer is not a peer on the network, then they cannot send mail to the other peers.
If only one sides runs their own SMTP, that only solves one side of the equation. Almost every HN discussion of user-controlled e-mail focuses only on users controlling one side, while ignoring the other and leaving it to third parties. That can still have benefits such as not storing mail with a third party, but obviously only focusing on one side, e.g., the receiving side, will fall short of true "user-controlled e-mail".
User-controlled e-mail is a solvable problem for most users, i.e., those whose contacts in a given context, e.g., personal, school, or work, are under 100. User-controlled e-mail is an unsolvable problem for people who want to send e-mail to 100s of people, e.g., people they do not know, or people who want to recieve e-mail from any random person/organisation, treating their address like a phone number on a bathroom wall. Maybe, for most users, that is actually a good thing. (Given the attitudes toward "spam", it appears most users generally do not appreciate unsolicited mail.) There could be separate systems for unsolicited mail. We already have such systems in place.
I was thinking of stopping to use gmail and hotmail, and run my own webmail client on a droplet. I don't like the idea of all my documents being tracked. Is there anything that competes with them that I could deploy.
Sieve is pretty cool; it runs user-defined scripts server-side, on delivery to addressee's mailbox. The scripts are in the Sieve language, which is just for mail filtering. But it's a bit abstruse - it may be rudimentary, but most users don't want to tangle with a language at all.
Anyhow, the Roundcube UI includes natively a Sieve script editor made up of drop-downs, which makes it much clearer what filter-steps you're asking for. I'm rather minimalist; I prefeer Squirrelmail, if I have to use webmail. But this feature of Roundcube is really good.
This means that you don't have to synchronize your filters between mobile client A, laptop client B, webmail client C. Thy're all on the delivery server (which is usually the same as your IMAP server). The filtering happens before you log in to email, and before your client knows there is an email.
Sieve is a specification, not a product (and not some specific PHP script). It's part of the Dovecot package in the Debian distro. It's client-server, only because there is a protocol for a client to upload/update scripts. So there's a wire protocol for management. But it has nothing to do with retrieving mail. Sieve on the server only affects what happens on delivery.
I think Sieve is totally the sanest way to do per-user mail fitering.
Initial setup of my mail server and related bits took a few days. Ongoing maintenance over the years? None, basically.