On 8/18/20 4:25 PM, james wrote:
I find all of this *fascinating*.
;-)
So I have threads from 7/28 and others that attempt to discover the
(gentoo) packages necessary to run my own email services. I have (2)
R.Pi4 (8Gram) and (2) more on order to build out complete
mail/DNS/security for a small/moderate number of folks to use. Just me
to start/test/debug.
I expect that, other than CPU speed, the four systems that you have are
probably overkill.
The CPUs may, or may not, be slow depending on the number of messages
you want to handle a day. They are probably quite adequate to start
with for personal email.
I'd like to build out Grant(Taylor) and Ashley's solution for further
learning and testing, on Rpi4 based gentoo systems. robust security and
reasonable straightforward (gentoo) admin, is my goal.
Sorry to be pedantic, but please list out what you mean by "robust
security". I ask more as an exercise for you to think about, and — more
importantly — document goals that you'd like to achieve. This
documentation may seem somewhat silly, but as has been mentioned
multiple times in this thread, there are a LOT of options. So,
documenting your desires helps reduce compatible options and makes some
choices for you.
Don't worry if you find that your previous choice limits you. That will
happen. You then need to decide if you want to live with the choice
-or- go back a few steps and change your choice.
Note: Changing your choice is perfectly fine. Call it what it is, a
change, and deal with it.
The documentation you're creating is sort of a proto / alpha checklist
of goals that you want to achieve.
Can either or both of you concisely list what I'd need
(the ebuild list) to implement a basic, but complete, secure email
system, as delineated in your recent posts? I'd be willing to document
both the build and running tests, for the greater good of the gentoo
community.
I will have to collect a list and get back to you.
Note: My list will be biased towards my choices. Given that I do
things differently than many email admins, my list is likely to be
considerably different than others.
If there is interests in the tests and results.
I think that quality documentation is always a laudable goal.
Remember, I started this some months ago, cause Frontier does not even
offer basic email services. I hate all thing cloud (deep desire to be
100% independent of the cloud) and want the ability to remotely
retrieve mails and send emails through *my email systems*. I am
certainly not alone, as some have sent me private email,
with similar desires.
Fair enough.
The big corporations are trying to destroy and remove standards based
email from the internet.
I haven't seen much where the big players are trying to actively destroy
standards based protocols.
I have seen where the big players are requiring higher and higher
standards than they did 5 / 10 / 15 years ago.
Note: This is neither breaking nor removing standards. If anything,
it's adding new public standards and making people adhere to them.
Analogy: Some states in the U.S.A. aren't removing old vehicles from
the road. They are however introducing requirements for vehicles to
adhere to more strict emission standards -or- register as historic
vehicles which imposes some restrictions.
For me, it is my most useful, important and most desired feature of
the internet.
I find email (SMTP(S) & IMAPS) and Usenet news (NNTP(S)) to be two of
the most critical Internet services to me.
The web (HTTP(S)) is extremely convenient. But I could live without the
web, admittedly reluctantly.
I'm ordering up (6) static IPs from Frontier.
Will this be an 8-block (/29) of globally routed IPs? Or is it going to
be 6 random IPs in a larger co-mingled IP network?
Start inquiring of Frontier about how to configure Reverse DNS. Chances
are good that Frontier will be familiar with RFC 2317 — Classless
IN-ADDR.ARPA delegation. — If you're not familiar with it, I suggest
you read RFC 2317.
I'd also suggest starting inquiries of Frontier if they Shared Whois
Project (SWIP) and / or RWhois. — My VPS provider doesn't offer SWIP
or RWhois, and I wish that they did. — SWIP and / or RWhois are quite
nice to have when it comes to making your IP(s) / block(s) stand out
from other IP(s) / block(s) near yours. (Think in the same /24).
Note: Many things on the Internet prefer for name servers to be in
different /24 networks. So, having multiple on different IPs in the
same /24 doesn't count to many people.
At some point, I'll put another primary bandwidth provider under
this,
I would encourage you to start with a bandwidth provider that you plan
to stick with for a number of years. (I know, things change. Do the
best you can with the information you have at hand now, and deal with
change if / when it comes.)
I say this because it takes a fair bit of effort to turn up a mail
server, especially one intending to /send/ to the Internet at large.
Sure, you can largely re-use the system configuration. But there is
quite a bit of work / effort / reputation around IPs, especially for
/sending/ email servers. It's enough effort that I would hate to do it
for one provider if I knew that I would be switching to another provider
in the short to mid term future.
Such a future change would influence what windmills I would tilt at;
e.g. RFC 2317 delegation vs traditional NS delegation for the IP(s) in
question.
with hopefully the ability to "bond the pipes" via BGP4 or another
capable protocol.
With little exception, "BGP" and "Internet" almost always mean a /24
sized prefix, your own provider independent IPs, and your own AS. These
are decidedly non-trivial hurdles to jump over.
Some providers /might/ be willing to form a BGP neighbor / peer session
with you under other circumstances. But they are for more specific
things and likely don't achieve the goal that I think you want.
There really isn't much other than BGP that is used on the Internet
between independent business / individual entities.
To do BGP with multiple upstream providers, you're really starting to
talk about a small ISP level. One that's got multiple upstream
providers. Many small ISPs are single homed.
It is possible to have multiple smaller, non-BGP, redundant ISP
connections. But you will almost always do it as separate systems that
are addressed out of the different ISP links. This can be another
entirely separate thread about how you do this. The TL;DR is that MX 10
looks like it's on ISP Red and MX 20 looks like it's on ISP Green.
Keeping the list of codes to a minimum, is appreciated, at least
until I get the (2) boards up and running. Previously, IPv6 address
mapped to these boards was suggested. I do not see any reason why both
ipv4 and ipv6 cannot be mapped (routed if you like) to these R.pi.4
boards simultaneously or separately, based on the test vectors under
developmental/proof study?
Yes, you can easily have both IPv4 and IPv6 on the same systems. This
is commonly known as "Dual-Stack".
/My/ personal and professional opinion is that Dual-Stack is currently
the industry best practice. That being said, I'm sure that there are
many that will try to sway you one way (IPv4 only) or the other (IPv6
only). — IPv4 and / or IPv6 is another one of those pesky choices that
you need to make. Well, unless someone else makes it for you.
Sorry for "jumping" this wonderful 'diatribe' but if I post directly,
via Verizon, to gentoo-user, it mostly bounces (another problem).
Verizon is dumping their email services too:
Ya. Many medium sized players are getting out of the market. We are
ending up with a few extremely large players providing end user
mailboxes and a lot of tiny providers providing mailboxes for a few users.
https://wiki.gentoo.org/wiki/Complete_Virtual_Mail_Server
https://www.howtoforge.com/perfect_server_gentoo_2007.0
https://www.androidpolice.com/2020/08/15/this-smartphone-has-physical-kill-switches-for-its-cameras-microphone-data-bluetooth-and-wi-fi/
I would encourage you to read all of these and try to understand all of
them. You will likely find that you agree with some points and disagree
with other points. This is where those choices, and documentation there
of, come into play.
You will likely learn something at some point that makes you want to
change a choice. I want to remind you that changing a choice is
PERFECTLY FINE! But, stick with what's documented, or make a new choice
and change what's documented. ;-)
motivated and curious,
#staycurious
--
Grant. . . .
unix || die
