[HN Gopher] Small mail server best current practices
___________________________________________________________________
Small mail server best current practices
Author : ebcase
Score : 189 points
Date : 2020-07-26 17:31 UTC (5 hours ago)
(HTM) web link (bridge.grumpy-troll.org)
(TXT) w3m dump (bridge.grumpy-troll.org)
| elric wrote:
| Not sure if I want to carry on host other people's email anymore,
| it's become a huge pain. It's bad enough that Google and MS
| frequently refuse to deliver mail; without any apparent reason or
| any humans to discuss the problem with. But now that zimbra is
| dead (no new open source versions), email hosting is pretty much
| back to where it was in the 00s.
| Cyph0n wrote:
| I went through the journey of configuring Postfix for a small
| side project I was working on.
|
| The idea was to accept emails sent to a unique, per-user address
| and forward all attachments to the user's cloud storage account.
|
| I looked into using mail services like SES and Mailgun, but given
| the average expected email size and the fact that I would
| primarily receiving mail, the additional cost didn't make sense.
| Along the way, I ended up learning quite a bit about Postfix
| filters, virtual domains, SPF, and DKIM.
|
| I also learned how quickly spammers can detect open relays.
| Apparently, while copy-pasting a config from somewhere, I had a
| slightly incorrect 172.x subnet listed as part of "mynetworks".
| As a result, a spammer with a machine belonging to this subnet
| was able to use my server as an open relay. Long story short, it
| took me quite a while to root cause the issue and get my domain
| off the blacklists!
| davemtl wrote:
| With all the fixes and standards just to send a cute cat GIFs to
| your friends on Gmail is such a pain in the butt for most self
| hosters. If you're doing it, great! Keep it up! All the better
| for you. But for me, using a e-mail hosting provider with a good
| reputation is preferable, they've already done all the hard work
| (my preference is FastMail, but it's not everyone's cup of tea).
| I've been in the IT field for almost 20 years, I've done the self
| hosting e-mail thing. In my early teens and 20s, I didn't have
| anyone to please or take care of, so keeping up was easy with new
| e-mail standards as they rolled out, 15-20 years later, I'm
| divorced, work full time and have two kids, I simply don't have
| the time to self-host anymore. I'd rather give somebody a few $ a
| month to take care of that for me.
| saimiam wrote:
| > I'd rather give somebody a few $ a month to take care of that
| for me
|
| I'll do it though i'm not FastMail!
|
| I'm working on a SES backed email client so SES takes care of
| deliverability (assuming the user does the basic DKIM, MX, TXT
| set ups) so it will work out much cheaper to send and receive
| mails than a FastMail/GSuite type solution.
|
| Plus you'll get unlimited disposable emails for free, a shared
| inbox (if you want to share an inbox with your family to help
| stay on top of every one's schedules, for exam), and while the
| client I have built is pretty rudimentary, i'll be adding bells
| and whistles to make it better.
|
| Github @ https://github.com/saiorama/ses-email-client Landing
| page to submit a request @ https://shared-inbox.landen.co/
|
| Note to others - I'm open to collaborating to take back email
| from the big guys. Hit me up via Github.
| anamexis wrote:
| This just seems bizarre - why?
|
| If the point is to take back email from the big guys,
| building on top of AWS SES seems to do exactly the opposite
| of that.
|
| It's built on a completely proprietary service, which you
| have very little control over. If you're having issues with
| it, you're SOL unless you're paying for an AWS Support Plan,
| which is already well over the cost of Fastmail etc.
|
| And on top of that, now you are stuck on a specific web email
| client as well, instead of POP, SMTP and IMAP which all of
| email has been running on for decades.
| hkt wrote:
| I've been so irritated with self hosting I've gone the other
| way: I'm in the process of setting up an email hosting co-op,
| with the aim of paying for managed service from a small hosting
| provider for most things but paying no more than I do now. That
| way it won't only fall to me to deal with deliverability issues
| etc.
| saimiam wrote:
| See my sibling comment to yours! I think we are both working
| towards the same goals. Nice to meet you.
| jks wrote:
| Addendum: if you host a mailing list server such as Mailman,
| you'll need to do one of (1) don't change the content or DKIM-
| signed headers at all (e.g. by adding Subject tags or unsubscribe
| instructions); (2) rewrite the From: header so that you don't
| look like you are impersonating the individual senders; (3) use
| ARC [https://en.wikipedia.org/wiki/Authenticated_Received_Chain]
| signatures. I don't know if Gmail and the other big providers
| actually honor ARC headers yet, but if they ever do, that would
| seem to be the cleanest solution if you need to add unsubscribe
| instructions or similar banners.
| thoraway1010 wrote:
| The volume of spam is mind boggling. When we first implemented
| DMARC / DKIM etc our legit emails were 3% or so of all outbound
| mail per the reporting we got back! We have a somewhat trusted
| domain.
|
| Some mail delivery systems start to notice that your domain name
| is being used as part of a lot of spam / bogus emails, so you can
| have perfect IP history / no spam and STILL start triggering some
| random filters (no big players but smaller protection product
| filters).
|
| So the game must be absolutely never ending for everyone and the
| inbox a valuable target - especially now that unsolicited phone
| calls really do seem to get ignored these days - I feel like
| spammers killed the golden goose on phone calls and the telcos
| let them.
|
| I will say DKIM / DMARC is working well, except google (which we
| now use for outbound) gives us transient SPF errors even though
| we are 100% using their IPs. Not sure why that is (ie, SPF
| failure on an IP that should clear)
| guerby wrote:
| I wonder if there's an ansible playbook implementing all that?
| ireflect wrote:
| Sovereign does most of it:
|
| github.com/sovereign/sovereign
|
| I was an early contributor to Sovereign and used it for many
| years, but I found that we kept adding features to it and it
| got too large for my liking. Now I use docker-mailserver:
|
| https://github.com/tomav/docker-mailserver
| gertrunde wrote:
| I looked at Sovereign a while back, and came to the same
| conclusion, and ended up going with mail-in-a-box, which is
| possibly a little too far the other way, but at least very
| low maintenance.
| evilsetg wrote:
| Thank you! I recently managed to get a static IP and was looking
| forward to set my own mail server to be independent of the big
| providers. Now I have been searching for something exactly like
| this, a recent, concise overview of the hoops I have to jump
| through to be allowed to send to the big guys.
| saimiam wrote:
| I wrote one as well @ https://medium.com/@ssr233/get-
| disposable-emails-for-your-do...
|
| I'm also trying to build my own email client for SES @
| https://github.com/saiorama/ses-email-client. Happy to
| collaborate in case you want to work on this issue.
| niftylettuce wrote:
| I made Forward Email after running into many issues with self-
| hosted solutions (and realized thousands of others have the same
| issue due to the high-demand after launch back in 2017). It's a
| great alternative to having to set up your own small mail server.
|
| https://forwardemail.net
|
| P.S. I'm coming out with a fully-fledged email service built on
| top of my R&D with Forward Email.
| cyberpunk wrote:
| Where are your servers located?
| niftylettuce wrote:
| Our existing infrastructure is hosted on dedicated (not
| shared) hardware in the US, UK, and Europe. Our new
| infrastructure (which will be running on bare metal servers)
| will be hosted in the US and Sweden (in underground bunker
| data centers).
| throwaway2048 wrote:
| Having the top reply to an article about hosting your own
| e-mail be somebody shilling their service based around the idea
| of how you should not in fact, run your own mail service is a
| bit gross.
| dochtman wrote:
| Will the fully-fledged email service also be open source?
|
| (This is the first time I've become aware of Forward Email
| despite having run my own forwarding email server for years --
| you should do more/better marketing/outreach!)
| niftylettuce wrote:
| Yep, everything I create is open-source!
| tux1968 wrote:
| I'd still have to have a mail server somewhere that receives
| the messages your service forwards to me though? Your service
| just provides one level of indirection, correct? Edit: and what
| about outbound email?
| niftylettuce wrote:
| We are going to release outbound/inbound SMTP feature soon,
| so you can use our service outside of Gmail (and others')
| 'Send Mail As' features. If you sign up (and don't add any
| domains or anything) I will send you an email when it's live.
| Or you can follow me on Twitter or subscribe to the GitHub
| releases. Or I guess you could just email
| niftylettuce@gmail.com and I will put you on the list to send
| to, haha.
| CraftThatBlock wrote:
| Any cheap paid services for this? I'm not comfortable with
| routing my emails through a free third-party.
| 627467 wrote:
| Forwardemail.net seems to have paid plans.
|
| Reading through the about and FAQ they also seem to be driven
| by decent principles.
|
| https://forwardemail.net/en/faq#how-is-it-free
| niftylettuce wrote:
| Yep! Both free and paid. We have some pretty serious
| security principles. I'm the creator, so if you have any
| questions let me know. All of my work I do is open-source
| -- and we also have a public Slack channel and Twitter
| where I post updates. The paid plans are for if you don't
| want to use free DNS-based forwarding setup, a small fee
| for unlimited domains/aliases/etc to help me maintain
| server costs (see the FAQ). I may make Enhanced Protection
| available for free at some point in the future, but I built
| it this way at first because the website used to be a
| simple wiki, and I used the DNS-based setup myself 2 years
| ago.
| dejj wrote:
| Then how are you comfortable routing it through a cheap
| service instead? Asked more precisely: how do you determine
| reliability from price?
| namibj wrote:
| It's more that you tend to get some legal implications from
| selling a service vs. having some website with no payment
| on the net.
| niftylettuce wrote:
| We do offer paid plans with enhanced features.
|
| And we're completely open-source, store zero logs, and store
| zero metadata too. All source code is on GitHub as well.
|
| I formerly worked at DuckDuckGo, and take privacy very
| seriously.
|
| Privacy Policy: https://forwardemail.net/privacy Terms:
| https://forwardemail.net/terms
|
| You can delete your account at any time.
| davidbrennerjr wrote:
| Eh, I didn't read it...so my thoughts. From experience the prob
| with DNSSEC is latency in verifying PKI of the record. Usually
| what happens is the timeout per resolver has to be greater than
| 15 seconds under no load in a private network which is very
| inconvenient in comparsion to plain DNS that has a default of 5
| seconds.
| icefo wrote:
| Tangentially related but I'm having some issues related to email
| beeing refused by Gmail.
|
| In my organization we have ~10 linux VM and they are all
| configured to send email to an exim MTA. For example monitoring
| stuff. The system mail name is set to vmName.srv.domain.name
| (domain.name is replaced by our actual domain and this resolve to
| a local address) so it's quite common to receive mail from
| root@vmName.srv.domain.name. This cause no issue when it's
| delivered to the local Cyrus server but when it's transfered to a
| Gmail address for some reason Gmail reject the email because the
| headers are bad.
|
| I am considering rewriting the address to
| user.vmName.srv@domain.name in exim when receiving email from
| local VMs and I am wondering if this could be a bad idea.
|
| I'm going to redo this mail server from scratch soon because it
| has been left untouched for something like 6 years. Some software
| was compiled on it with shared libraries which then were updated
| but the software was not recompiled. It's a dumpster fire and I'm
| actually surprised most of our emails seem to go through.
|
| I would also add to the article that's it's a good idea to have
| some rate limit on outbound email, outbound email spam checks and
| to check that the user sending email has the right to use that
| address.
| dillonmckay wrote:
| Are you using mxtoolbox.com or other third party
| troubleshooting services?
| johnchristopher wrote:
| Quick question (as someone who doesn't manage email): why not
| using an external mail provider (like mailjet) ? Privacy
| concerns and/or internal mails that shouldn't get leaked ?
| icefo wrote:
| That server is at least 10 years old and quite custom. For
| example when an email is received the address is queried to
| an ldap and if it's a mailing list the email is sent to all
| the recipients of that mailing list which can be other
| mailing lists ! This goes on until an user address is found
| and then the email is delivered to the cyrus server.
|
| Each user can also have many alternative addresses that map
| to an unique mailbox
|
| Those mailings lists are used a lot internally and managed
| with internally developed tools. This make migrating to an
| external service difficult.
|
| That's the classic example of some critical piece of
| infrastructure that nobody dare to touch because it works...
| until it doesn't anymore.
|
| That's why we don't use external services to receive email.
| I'll consider using mailJet if setting up exim & related
| stuff correctly to send email in 2020 proves too painful.
| dillonmckay wrote:
| Somebody else mentioned you could temporarily sign up for G
| Suite and use the same domain, and it will magically be
| whitelisted.
|
| I am assuming you have some budget for this.
| user5994461 wrote:
| If the reverse DNS/MX is configured to allow emails from
| @domain.name, then you have to send email with an address in
| @domain.name.
|
| @vmName.srv.domain.name is not configured so it goes to spam.
| deadalus wrote:
| I personally use zoho.com(free plan) for email to and from my
| domain. What is the use of self-hosting a email server over using
| Zoho or Gmail?
| acidburnNSA wrote:
| I like hosting mine for a few reasons:
|
| - It's a hobby and I enjoy it
|
| - It like fiddling around with advanced features, like wildcard
| addresses, server side filtering (via dovecot-sieve), and other
| fun stuff. For instance, a friend once was mulling on facebook
| on detecting tone of email and rejecting ones that were too
| mean. I made a simple python script that attempted this and had
| her try it out. It was funny. (See previous point about hobby)
|
| - I figure that being on your own server you're at least
| slightly less likely to be a victim of a big internal platform
| hack like twitter's recent one, or state-run ones.
|
| - It feels slightly badass.
|
| I don't recommend it to people who don't want to do it for fun.
| tgsovlerkhgsel wrote:
| There really needs to be
|
| a) a docker container (or other standardized, easy to deploy
| technology) with a "mail server in a box implementing best
| practices"
|
| b) a test for the stuff that Docker can't cover like DNS config,
| ideally with scripts to set it up on the most popular providers
| and clear copy&paste instructions for the rest.
|
| People shouldn't need to fully understand DKIM, SPF, etc. - they
| should just be able to click a button, copy&paste generated DNS
| records, and be up and running.
|
| Otherwise, commercial providers are just the only option that
| makes operational sense for most cases, _even if you know how to
| do it right_, because doing everything right manually step by
| step is still to much work to be worth it in many cases.
|
| None of this seems _hard_, it's just tedious.
| mawalu wrote:
| I use mailcow and it does both a) and b) very well. You can
| either selfhost or pay the developer to host it for you:
| https://github.com/mailcow/mailcow-dockerized
| mihaifm wrote:
| Try https://github.com/tomav/docker-mailserver
|
| It's pretty good, I use it for my own server. It still requires
| some config, but better than running all the services from
| scratch.
| pbhjpbhj wrote:
| Agreed. A few years back when moving my personal domain from a
| failing provider I considered running my own email server on
| Digital Ocean; they had some great tutorials on setting up
| various parts and I followed a HN recommended tutorial. I was
| already happy setting up LAMP with a nginx reverse proxy, how
| hard could it be - I got it setup, and realised two things:
| Keeping everything running without getting compromised was
| going to take way too long compared to the benefit. Two, Google
| and MS wouldn't accept my email - not even to myself when I
| whitelisted it - it's a crap shoot.
|
| Email has serious economies of scale and keeping such a
| critical system operational, on a small scale, was going to be
| some deal of stress.
|
| So I just went with my hosting providers Plesk-fronted setup,
| which matches your para.3 description.
| gsich wrote:
| >People shouldn't need to fully understand DKIM, SPF, etc. -
| they should just be able to click a button, copy&paste
| generated DNS records, and be up and running.
|
| I oppose this. People should know what they are configuring.
| This applies to all stuff related to mailservers.
|
| You probably learn more by setting it up the "hard" way
| (without containers) so that in case of failure you at least
| have a little insight in how the components work.
| im3w1l wrote:
| There are many more people who want to drive a car, than
| people who want to learn the minutiae of how it works.
|
| If it breaks, then you get someone else to fix it / get a
| better product is all they need to know.
| lifty wrote:
| A very promising project is https://github.com/foxcpp/maddy. It
| is an all in one server that can both receive and send email.
| gboss wrote:
| For A) I believe that is what https://mailinabox.email/ is
| trying to achieve
| pgrote wrote:
| Running an email server became a real pain about 4 years ago.
| Until then, we could run our own exchange server, control
| everything and it was awesome. Then came the email security
| products from the large companies.
|
| It became a self fulfilling prophecy. Our email would trigger a
| rule in big co's third party security app, which would then
| report to a centralized rule breaker clearing house
| automatically. Clients couldn't receive our emails, we would dive
| in, submit appeal to clearing house, get clear and a week later
| do it all again.
|
| Everything was configured properly on our end. We passed all the
| online validation engines. IPs were our own personally owned
| block and pristine.
|
| It became too much.
|
| Switched to office365 and all problems magically disappeared.
| Sent emails to same big cos with third party email security and
| haven't had a single issue.
| throwaway2048 wrote:
| Yep, you can do everything outlined in the article and have an
| IP that has not send spam in 10+ years and gmail will still
| spambox every single one of your mails.
|
| However if a domain signs up for Google Apps, magically you get
| whitelisted, even if you are handling your own email, funny
| thing that.
|
| I guess Google's customers are just more trustworthy...
| luckylion wrote:
| > I guess Google's customers are just more trustworthy...
|
| I wish. I've been having issues with being sent to spam when
| replying to a colleague on the same domain which is on
| Google. The email never left their servers, everybody was
| authenticated, and the emails were within an hour of each
| other, so it's pretty obvious that it's a reply. Still: off
| to spam it went.
|
| We now have a filter rule to always consider our own domain
| as not spam, because it's just too unreliable otherwise.
| petters wrote:
| This is a really annoying Gmail+Gsuite bug that has
| affected us as well. Surprising that it seems to happen
| this often.
| colordrops wrote:
| Is the implication that this is an intentional practice to
| drive out small players?
| jandrese wrote:
| I don't think it is an attempt to drive out small players,
| it's a natural consequnce of domains being almost free to
| stand up. They just don't provide any level of assurance that
| the owner isn't a spammer. So the blackhole systems treat
| them as "probably spammer" and fire up a block at the first
| whiff of malfeasance.
|
| It's harder to sign up for a Gmail account than it is to
| register a domain and get some hosting. And Google has their
| own protections against sending large amounts of mail built-
| in. The system is as it is now because spammers will abuse it
| otherwise.
| throwaway2048 wrote:
| gmail is effectively block by default these days, unless
| Google has some reason to not block your mail, it will be
| spamboxed.
| bachmeier wrote:
| True. It's a mistake to do a job search using gmail.
| Interview invitations and job offers are going to go
| straight to spam.
| alyandon wrote:
| Sending email to Google is always a crap shoot and I
| still find to this day that sometimes when I send email
| contains logs to my own account using my own account
| credentials it'll end up being classified as spam.
|
| Right now, Google is refusing to deliver email from
| logwatch - giving me the "Message rejected. See
| https://support.google.com/mail/answer/69585 for more
| information." so those are going to /dev/null with no
| recourse to fix it because Google literally doesn't like
| the content of the email.
|
| The fact that I can't hit a button and tell Google that
| yes indeed I'm not trying to spam myself is ridiculous.
| vbezhenar wrote:
| That was the case for me few years ago. But I decided to
| set up mailserver once more recently and Gmail to my
| surprise accepted my mails. I configured everything
| mentioned in article.
|
| That said, my outcoming mail traffic is almost non-
| existent outside of few test emails, LoL.
| EvanAnderson wrote:
| I don't think it's done intentionally, but I also don't think
| the big players go out of their way not to harm the small
| ones. All the big email players would love to take your money
| to "outsource" your email.
| g-garron wrote:
| I really think so. They are forcing everybody into their
| services.
| csunbird wrote:
| No, I think that there are just too many spammers, so big
| players have no choice except to make it hard to own your
| mail server until your server gains positive reputation.
| nbandv wrote:
| I don't think there are many spammers compared to, say,
| 2005.
|
| In 2005 you would get 100 spams to an unfiltered, widely
| published address, these days it is more like 2-5.
|
| The continued lockdowns and protocol changes of gmail and
| yahoo are a sign of being overstaffed, "feature" oriented
| and yes, the attempt to shut down competition and the free
| exchange of mail.
| user5994461 wrote:
| You're lucky if you only get 2 spams a day. My parents
| are getting more like 20-50 a day on the email provided
| by a national ISP.
|
| It's getting impossible to read emails, too many. If it
| were not for them being used to their email address and
| me being lazy, I would move them off to gmail.
| csunbird wrote:
| I do not think so, I think the spammers are still out
| there, armed with cheap cloud email providers, but the
| "block by default" is putting a nice dent on them.
| rsync wrote:
| Ugh.
|
| I have been running my own UNIX mailserver since 1997. I have
| consistently and loudly evangelized this practice, especially
| here on HN, and pushed back against the notion that it was too
| difficult or too time-consuming to implement and maintain one's
| own mailserver.
|
| But ...
|
| Having just recently made the _major_ transition from relying
| _solely_ on clean IP space and proper DNS records (which, in the
| last 18 months, has become increasingly untenable[1]) I have
| changed my mind.
|
| I will continue to run my own mailserver, for activist,
| ideological reasons, but I must now agree that it is too
| difficult and complicated - and fragile.
|
| In no particular order, some of the things that I find overly
| complex and disturbing are:
|
| - The DKIM implementations are very, very over-engineered. I
| understand, in principle, why we want DKIM to be a pluggable
| component that can be used as a general building block in various
| implementations, blah blah blah, but there is _no reason_ that
| DKIM can 't just be a feature, with a corresponding blob of
| config lines, in sendmail or OpenSMTPd or whatever. Having to
| pkg-install, and track, and maintain, whatever DKIM
| implementation you choose, along with all of its various
| dependencies, etc., is a big truckload of complexity and
| fragility that I just can't see ever appreciating. And the irony
| ? A popular DKIM implementation is to use the bundled DKIM
| functionality built into rspamd (!) ... so it ended up being just
| a feature anyway.
|
| - The whole SSL component ... I appreciate this, I understand
| this, and for many use-cases I just don't care. I don't currently
| need encrypted email and if someone makes a decision to disallow
| sending to addresses/domains that don't support it, fine. Of
| course, if _all of gmail_ decides not to, now I have another
| giant truckload of complexity and fragility that I need to
| implement and maintain. My mailserver should be an extremely
| tight, stripped down host with as few packages and daemons
| possible[2]. Instead, I am now installing a big list of packages
| just so that letsencrypt can fire up a _temporary web server to
| clicky click make my certificates_ [3].
|
| - Now my mailserver is running a database (Redis) which is
| required to run rspamd, which is required to implement DKIM,
| without which I cannot send mail to yahoo.com addresses. True
| story.
|
| So much complexity and fragility ...
|
| [1] About 18 months ago yahoo.com stopped, with no errors or
| bounces, delivering mail from an 11 year clean IP with proper
| DNS/MX entries. I implemented DKIM and the problem is solved.
|
| [2] My mailserver is a FreeBSD jail and previously ran only
| sendmail - and nothing else. Now I am running OpenSMTPd, rspamd,
| redis ... and once in a while I am running a webserver to
| communicate with letsencrypt.
|
| [3] Speaking of letsencrypt ... requesting, generating and
| implementing SSL certs (even for use on the web) is simply
| creating, and trading, blocks of plain old ASCII text. I haven't
| looked into this, but is there an "expert mode" somewhere in
| letsencrypt where I don't have to run webserver instances and ...
| I can just run openssl command lines and cut and paste blobs of
| ASCII ?
| tialaramex wrote:
| > [3] Speaking of letsencrypt ... requesting, generating and
| implementing SSL certs (even for use on the web) is simply
| creating, and trading, blocks of plain old ASCII text. I
| haven't looked into this, but is there an "expert mode"
| somewhere in letsencrypt where I don't have to run webserver
| instances and ... I can just run openssl command lines and cut
| and paste blobs of ASCII ?
|
| Let's Encrypt provides an ACME service. So, you will want to
| (run something that can) speak ACME, a somewhat RESTful HTTP
| API documented in RFC 8555 -
| https://tools.ietf.org/html/rfc8555. You can use a web service
| to do this part, but then you're relying on some random web
| service and you have to manually do a bunch of steps to renew
| at least every 90 days which I'm going to assume you agree
| sucks.
|
| There are lots of people who have built such tools that can
| look after this for you automatically, perhaps you would like
| https://acme.sh/ which as its name might suggest is a shell
| script.
|
| Let's Encrypt offers three of the (increasingly misnamed) Ten
| Blessed Methods, you can prove control over a DNS name by doing
| any of these three things:
|
| 1. Running an HTTP server on port 80 which can answer certain
| well-known requests in a specific way acknowledging your ACME
| keys. This server needn't have any privileges, acme.sh can help
| you spin one up that will basically say "Yes, rsync is allowed
| this certificate" for any request. Except instead of "rsync"
| it's a key only you have, so your server answering this way
| never helps any bad guys so long as you keep your ACME keys
| secure. [You may not be aware you have "ACME keys" the software
| you've used probably just minted some and squirreled them away
| in a dot directory]. With that server in place, your requests
| for a certificate for that name will always work, because the
| key matches, Let's Encrypt will call your server, make up a
| random nonce and ask if that's authorised and for who, your
| HTTP server will always answer "rsync is authorised" so it
| works, tidy.
|
| 2. ALPN on port 443. A TLS server answering port 443 can accept
| a special ACME-only ALPN protocol choice from the Let's Encrypt
| servers and use that to prove control. You almost certainly
| don't want this unless you implement web servers (which run on
| port 443 with TLS already)
|
| 3. DNS queries for a magic name that can't be a hostname. The
| queries ask for _acme-challenge which has an underscore in it.
| Underscores are allowed in DNS but can't be hostnames, which is
| fine because this isn't a hostname. Your ACME client will need
| to write to DNS, it can either have a way to write to your
| actual DNS, or you can use a CNAME to redirect the names you
| need to another DNS server and give the ACME client control
| over that. [Edited to fix DNS name mistake]
|
| You can insulate the ACME client from the server completely
| with either the trick I described in (1) or using DNS like (3)
| _and_ using a Certificate Signing Request, CSR, which is one of
| the many ASCII text blobs you can get from OpenSSL. If you 're
| comfortable re-using a private key for longer periods than the
| 90-days assumed in Let's Encrypt (a 2048-bit RSA key seems safe
| to me for the usual lifetime of a mailserver) you can even re-
| use the same CSR again and again to request each new
| certificate without sending _any_ data from the mail server to
| the system calling Let 's Encrypt.
|
| You will need to arrange to get each new certificate installed
| (the private keys don't change in this scenario). But
| certificates are public documents, if it came to it the mail
| server can (this is _very_ silly but it would actually work)
| just wait until 24h after the certificate should have been
| issued and then go get it from https://crt.sh/ -- In reality
| you can probably find some sensible way to get this public
| information back to the mail server each time the certificate
| is renewed.
| _jal wrote:
| Fellow long-time self-hoster. I hear you on a lot of this.
|
| Regarding letsencrypt, you can use DNS challenges. See
| https://letsencrypt.org/docs/challenge-types/ .
| quesera wrote:
| I've been self-hosting email for 25 years also.
|
| I think of it as a process of punctuated equilibrium.
|
| Every several years (or ten), it requires a flurry of activity
| to update to new preferred daemons, or new hardware.
|
| Between these brief periods, everything is stable and solid. I
| don't have to think about it at all. In 25 years, I've rebuilt
| things 5 or 6 times. After the first few times, it has been
| more of a chore than an adventure, but it's still worth it to
| me, for now.
|
| One development that might change my mind about that:
| Ubiquitous and non-vendor-dependent MFA. If email was not the
| security mechanism of last resort (or the skeleton key), then I
| might consider outsourcing it.
|
| ...
|
| Re: Rspamd: It works well, but I did not enjoy the
| configuration effort. And yes, I never wanted Redis on my
| mailserver, but there it is -- along with an astonishing amount
| of RAM usage, which offends me in theory even if it has no
| practical impact. On the positive side, after the initial few
| hours of effort to get things set up, I have spent zero hours
| maintaining any of it, so I can't reasonably complain.
|
| Re: letsencrypt: I use dehydrated for certificate renewal, and
| I run a temporary webserver as you describe. Not a full
| dedicated webserver package, just python (or ruby) which is
| already installed. It's launched from the same script that
| automates the license renewal. Not elegant, but adequate. You
| could probably get away with netcat.
|
| Of course you can validate by DNS instead of HTTP. But that's
| not always convenient either.
| rsync wrote:
| "Every several years (or ten), it requires a flurry of
| activity to update to new preferred daemons, or new
| hardware."
|
| I think you are correct and this is a decent description of
| how this has worked.
|
| I don't begrudge the every 5-10 year burst of
| activity/implementation. What I begrudge is the _increased
| complexity_. We 're both talking about Redis as a hard
| requirement for rspamd which is the typical recipe for
| implementing DKIM which is required for email. _That 's a lot
| of moving parts_.
| throwaway2048 wrote:
| There are much simpler ways to implement DKIM than you have
| done, not sure why you have chosen such a massively complex
| one, for instance
|
| http://dkimproxy.sourceforge.net/
| rsync wrote:
| I think the reason rspamd+DKIM is so popular is that you're
| going to run a spam daemon anyway so ...
| iMerNibor wrote:
| ..and even if you follow all the best practices you'll just
| randomly end up blacklisted for what I can only imagine is
| misguided users clicking on spam.
|
| If that happens on the wrong email provider you're out of luck.
| One of the mail servers I have a hand in has been blocked by
| one of those difficult providers for the past 2 months and we
| sent them 4 mails/week before the block on average :)
| cm2187 wrote:
| Point 14 is a very good one. If any account gets compromised, you
| might as well request a new IP as your previous IP will be in the
| dog house for a long time.
|
| Almost more important than monitoring failed logons, monitor
| successful logons, for instance by country. If it is a small mail
| server, chances are your users are in a handful of countries. If
| you suddenly see a successful logon from vietnam or brazil, you
| probably want to be notified ASAP.
| juskrey wrote:
| Mailinabox handles all of that automatically and nicely. You just
| need to do some manual DNS work and check your IP against
| blacklists on http://multirbl.valli.org/ - and mostly done.
| jeffbee wrote:
| I think part of the point of the post and the PDF to which it
| links is that Gmail and the other big operators don't use the
| blacklists, so for deliverability to the majority of recipients
| it makes no difference whether you are or are not on those
| lists.
| jeffbee wrote:
| Example of how the blacklists contain essentially no
| information: every one of Gmail's outbound VIPs is in a SORBS
| blacklist. Every one I checked is in at least 20 other
| blacklists. So if you just don't want to get mail from
| hundreds of millions of people, subscribe to IP blacklists.
| johnklos wrote:
| That's not true, unless "VIP" means something that I don't
| understand.
|
| I use SORBS on a rather busy mail server with thousands of
| messages sent to and from Gmail daily. Aside from very
| occasional SORBS rejections, which happen more often with
| Outlook.com and Yahoo, this simply isn't the case.
| jeffbee wrote:
| See for yourself:
|
| http://multirbl.valli.org/lookup/209.85.128.65.html
| e12e wrote:
| Seems to be mostly not listed?
| jeffbee wrote:
| Sure but blacklists are binary. That's why they don't
| work.
| e12e wrote:
| It's perfectly fine to check 282 blacklists and treat
| only N hits as a positive?
| johnklos wrote:
| "every one of Gmail's outbound VIPs is in a SORBS
| blacklist. Every one I checked is in at least 20 other
| blacklists"
|
| I still don't understand your statements. That's simply
| not true. It's not even close to being true.
| jeffbee wrote:
| Post a Gmail outbound VIP that is not in a SORBS
| blacklist, then, if you're so sure.
|
| Whatever the opposite of a disclaimer is: I was the tech
| lead of gmail delivery SRE for four years, so it's likely
| that I know more about this topic than anyone on this
| board.
___________________________________________________________________
(page generated 2020-07-26 23:00 UTC)