On 8/17/20 5:33 AM, Ashley Dixon wrote:
How many concurrent users will be connected to the mail server? How
much traffic will the S.M.T.P. server receive (read: how many
e-mails arrive on a daily basis)?
My main VPS has a single digit number of clients and processes anywhere
between 50,000 and 200,000 emails per day. It does so without any problem.
If you really don't trust your V.P.S. provider, and your mail server
is small-ish, you could just skip all the trust issues and buy a
cheap Raspberry Pi for £20 or so.
The VPS includes a globally routed IP, something that a Raspberry Pi
doesn't inherently include. The connectivity, including reverse DNS, is
a big issue for running an email server.
Running a mail server over a domestic connection presents some
issues, such as dynamic I.P. ranges appearing in the Spamhaus
blocklist, or some tyrannicalesque I.S.P.s blocking outbound port 25
(S.M.T.P. submission port),
Nitpick: SMTP's /submission/ port is TCP 587. "Submission" is a very
specific term in SMTP nomenclature. Specifically client's /submitting/
email into the SMTP ecosystem. Server to server happens over the SMTP port.
I believe you mean the regular SMTP port, TCP 25.
but it is possible to have a smooth, self-administered mail server,
providing you can put in the time and effort.
Agreed.
ProTip: Running an email server is about more than just SMTP. You
really should have a good working understanding of the basics of
multiple protocols and technologies that are part of the email ecosystem:
- SMTP protocol
- DNS protocol
- POP3 and / or IMAP client access protocols
- MTA
- LDA
- Virus filtering
- Spam filtering
- SPF
- DKIM
- DMARC
- RBLs
- RWLs
- Client operations
- email ecosystem nomenclature
That's just the short list.
When I say "have a good working understanding", I mean that you should
be able to provide a 101 level 30-90 second description of each of those
items. Actual understanding, not just wrote memorization.
I have been doing it myself for a few years with Courier and Postfix
I've been doing it for 20+ years with multiple MTAs, multiple client
MUAs, multiple 3rd part <bla> as a service providers. None of any of
the components is difficult itself. The annoying thing comes when you
try to get multiple to interact well with each other.
(although I wouldn't recommend Courier; Dovecot is far superior).
To each their own. I chose Courier because it could do things that
Dovecot couldn't (at the time I made the decision) and fit my needs
considerably better.
Some of the things that you need to make decisions about are learned
about with experience, usually unfavorable experience. As in "crap, I
don't like the way that works". Thus you make a new decision.
There is (or used to be) much debate about should email accounts be real
and have backing Unix (OS) level accounts, or should they be virtual and
fall under the auspice of one single Unix (OS) level account that the
client access protocol daemon(s) run as. From a purely email
perspective, this might not matter. But it really starts to matter if
you want friends that have email with you to also be able to host a web
site with you and need to connect in to manage their site, thus needing
a Unix (OS) level account to do so.
What do you think?
There are MANY different ways that you can combine the things I listed
above. It is usually a personal choice. Some things that work out well
in one configuration are completely non-applicable or even detrimental
in another configuration.
There are many recopies to get started.
You really need to start somewhere, learn as you go, and make your own
choices.
--
Grant. . . .
unix || die
