Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?

[james]

On 8/18/20 4:36 PM, Grant Taylor wrote:
> On 8/18/20 5:59 AM, Caveman Al Toraboran wrote:
>> redundant as in containing concepts already done in other protocols,
>> so smtp has many re-invented wheels that are already invented in
>> existing protocols.
>
> Please elaborate.� Please be careful to provide information about /when/
> the protocols that SMTP is supposedly redundant of were developed.
>
> I suspect that you will quickly find that SMTP predates the protocols
> that you are stating it's redundant of.� I further suspect that you will
> find that SMTP predates them by 10, or more likely 20, if not 30 years.
>
> Here's a hint.� SMTP was ~82.� HTTP (1.0) was ~89.� We couldn't post
> thing in HTTP 1.0.� HTTP 2.0 was ~15.
>
>> basically smtp, as an application-layer protocol, is needless.
>
> We are all entitled to our own opinion.
>
>> imo, smtp should be a much-higher level protocol defined purely on top
>> of how dns and http/2.
>
> How do you get any higher layer than the application layer?
>
>> e.g. for mail submission, there is no need for a separate
>> application-layer protocol as we can simply use http/2.� because the
>> concept of mail submission is a special case of data submission, which
>> is already in http/2.
>
> HTTP /now/ has a way to submit data.� HTTP didn't exist when SMTP was
> developed.� Further, HTTP didn't have the ability to submit data for a
> while.
>
> If you look at multiple layers of the network stack, HTTP and SMTP are
> both at the application layer.� Now you are suggesting moving equal
> peers so that mail is subservient of / dependent on web?
>
> Does HTTP or the web servers have the ability to queue messages to send
> between systems?� How many web servers handle routing of incoming
> messages to send to other servers?� How dynamic is this web server
> configuration to allow servers for two people who have never exchanged
> email to do so?
>
> This routing, queuing, and many more features are baked into the email
> ecosystem.� Features that I find decidedly lacking in the web ecosystem.
>
>> here is a more complete example of what i mean:
>>
>> 1. we lookup MX records to identify smtp servers to submit mails to.
>> 2. from the response to that lookup we get a domain name, say,
>> mail.dom.com.
>
> #1 and 2 are par for what we have today.� No improvement.
>
>> 3. then, the standard defines a http/2 request format to submit the mail.
>
> Given how things never die on the Internet, you're going to need both
> SMTP /and/ HTTP /on/ /the/ /email/ /server/ to be able to send & receive
> email with people on the Internet.
>
> So you now have a HUGE net negative in that you have the existing
> service plus a new service.� You're in many ways doubling the exposure
> and security risk of email servers.
>
>> an example of step (3) could be this:
>>
>> ���� https://mail.dom.com/from=...&to=...&cc=...\
>> ���� &bcc=...&subject=...&attach1=...&attach2=...\
>> ���� &attachn=...
>
> If you were to do this, you would NOT do it via GETs with URL
> parameters.� You would do it as POSTs.
>
> You will also have to find a way to deal with all the aspects of SMTP
> and RFC 822 email + mime.� I suspect that you will find this to be
> extremely tricky.� Especially if you try to avoid SMTP / RFC 822
> semantics b/c SMTP is apparently a bad thing.
>
> How does your example scheme account for the fact that the SMTP envelope
> from address frequently diff from the RFC 822 From: header?� Remember,
> this very feature is used thousands of times per day.� So you have to
> have it.
>
> There's also many Many MANY other features of SMTP that are also used
> thousands of times a day that I'm seeing no evidence of.
>
>> ���� i don't know how http/2 works.� do they have
>> ���� POST requests?� if so maybe fields attach1,
>> ���� attach2, ..., attachn can be submitted as file
>> ���� uploads using POST.
>>
>> further, if we modify steps (1) and (2), we can generalise this
>> concept into tor services.� e.g.� an email address simply becomes an
>> onion address.� e.g. if vagzgdrh747aei0q.onion is the hidden service
>> address of your mail server, then your email address could be written
>> as (for convenience):
>>
>> ���� remco@××××××××××××××××.onion
>
> I ... I don't have the words.� Go run that idea past an SEO expert.
>
> Go ask people to drop their domain name in favor of a hash.
>
> I'm not going to hold my breath.
>
> How are you going to handle the billions of email clients that exist
> today, many of which will never be updated, to handle ToR?� You're going
> to have to have something to gateway old and new.
>
> That means that you're still going to have steps #1 and #2.� You can't
> get away from them without everybody and everything migrating to the new
> system.� Even then, chances are still extremely good that you're /still/
> going to have #2.
>
>> and when a "mail" client tries to submit you an email, it submits it
>> by this url:
>>
>> ���� https://vagzgdrh747aei0q.onion/to=remco&...etc.
>
> I haven't the words.
>
>> then, in order to authenticate a source, we simply use public-private
>> keys ...
>
> Because that has worked out so well and with so few problems in the past
> 25 years.
>
>> ... to sign messages.
>
> Even /more/ unlikely to be ubiquitously adopted.
>
>> basically, our public keys become our user identifiers.
>
> What?!
>
> Now you are taking away the human friendly name in addition to the
> domain name.
>
> People are going to be lined up to hang you.
>
>> this will also solve the problem of the case when an onion address
>> changes.
>
> I don't think so.
>
>> i call this protocol mailball for the purpose of making speech this
>> mail thread a bit easier.� of course, we can pick better names, and
>> refine the mechanics.
>
> There are a LOT of mechanics that need to be defined before they can
> even be refined.
>
>> for people who use the deprecated smtp protocol, yes, it will be
>> "don't spam us, we'll spam you".
>
> I think you'll find that your mail(fire)ball will be excommunicated form
> the rest of the SMTP speaking Internet and never gain enough traction,
> much less take over and become the norm.
>
>> however, that's not our fault.� they are using a deprecated protocol,
>> and we are just kind enough to allow them an opportunity to talk to us
>> over the superior mailball protocol.
>
> Oh, how graciously thoughtful of yo....� See my previous statement.
>
>> basically, they are using deprecated identifiers (email ids) instead
>> of public keys, and we're kind enough to give them a temporary api so
>> that we confirm their emails.
>
> LOL
>
>> on the other hand, people who use mailball will not have this problem.
>> why?� because ids are public keys anyway, and their messages are
>> signed by their private keys (the usual drill, won't insult your
>> intelligence).
>
> So, how will mail(fire)ball prevent me from creating as many key pairs
> as I want and sending you a message from each and every one of them? How
> does this do anything to prevent spam or viruses?
>
> How well does your security hold up when, not if, someone creates a
> gateway to make it trivial to send SMTP based email into mail(fire)ball?
>  �It will happen just after mail(fire)ball gets just enough traction
> that people scratch the surface to look at it.� That is if it doesn't
> happen as part of getting enough people Interested.� Or even your own
> ""API that you are graciously providing.


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'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.

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.
If there is interests in the tests and results.


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.

The big corporations are trying to destroy and remove standards based 
email from the internet. For me, it is my most useful, important and 
most desired feature of the internet.

I'm ordering up (6) static IPs from Frontier. At some point, I'll put 
another primary bandwidth provider under this, with hopefully the 
ability to "bond the pipes" via BGP4 or another capable protocol. 
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?


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:

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/

motivated and curious,
James