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

[james]

On 8/21/20 4:10 PM, Grant Taylor wrote:
> On 8/21/20 11:01 AM, Caveman Al Toraboran wrote:
>> yes, i do consider re-inventing octagonal wheels.
>
> I think that it's occasionally a good thing to have a thought experiment
> about how $THING might be made better.
>
> It's probably good to have discussions around green feel types of
> replacements.
>
> But it's important to eventually assess the pros and cons of the old (as
> it exists), the new (as from green field), and the transition between
> the two.
>
> Sometimes the new doesn't warrant the transition, but it does provide an
> option that might be worth augmenting into the old.
>
> If nothing else, it's good to have the discussions and be able to answer
> why something was done or chosen to remain the same.
>
>> here, i'm just "asking" to see what makes the "safely stored" guarantee.
>
> MTAs are supposed to be written such that they commit the message to
> persistent storage medium (disk) before returning an OK message to the
> sending server.
>
> There is some nebulous area around what that actually means.� But the
> idea is that the receiving server believes, in good faith, that it has
> committed the message to persistent storage.� Usually this involves
> writing the message to disk, probably via a buffered channel, and then
> issued system calls to ask the OS to flush the buffer to disk.
>
> Is there room for error?� Probably.
>
> Had the server made (more than) reasonable effort to commit the message
> to disk?� Yes.
>
> The point being, don't acknowledge receipt of the message while the
> message is only in the MTA's memory buffer.� Take some steps to commit
> it to persistent storage.
>
> That being said, there are some questionable servers / configurations
> that will bypass this safety step in the name of performance.� And they
> /do/ /loose/ /email/ as a negative side effect if (when) they do crash.
> This is a non-default behavior that has been explicitly chosen by the
> administrators to violate the SMTP specification.� Some MTAs will log a
> warning that they are configured to violate RFCs.
>
>> got any specific definition of what makes a storage "guaranteed"? e.g.
>> what kind of tests does the mail server do in order to say "yup, i can
>> now guarantee this is stored safely!"?
>
> It's more that they do something safe (write the message to disk)
> instead of risky (only store it in memory).
>
> Everything can fail at some point.� It's a matter of what and how many
> reasonable steps did you take to be safe.� Read: Don't cut corners and
> do something risky.
>
>> i guess you think that i meant that a relay should be mandatory?
>
> Sending / outbound SMTP servers /are/ a relay for any messages not
> destined to the local server.
>
> There is almost always at least two SMTP servers involved in any given
> email delivery.� All but the final receiving system is a relay.
>
>> (yes, a relay doesn't have to be used.� i'm just describing some uses
>> of relays that i think make sense.� (1) indicate trust hierarchy, (2)
>> offload mail delivery so that i can close my laptop and let the relay
>> have fun with the retries.� not sure there is any other use.� anyone?)
>
> There are many uses for email relays.� A common one, and best practice,
> is to have an /inbound/ relay, commonly known as a backup email server.
> The idea being it can receive inbound messages while the primary email
> server is down (presumably for maintenance).
>
> Many SaaS Email Service Providers (ESPs) /are/ relay servers.� They
> receive email from someone and send it to someone else.
>
> A number of email hygiene appliances function as an email relay between
> the world and your ultimate internal email server.� Services that filter
> inbound email qualify here too.
>
> It is common, and I think it's best practice, to have web applications
> send email via localhost, which is usually a relay to a more capable hub
> email server which sends outbound email.� Both of these layers are relays.
>
> A relay is the same thing for email that a router is for a network.

WOW do I love these discussions, but let me 'cut to the chase'.

I'm proposing, via a small corp I own, to purchase up to (3) dual 
Rasp.pi 4 setups of (2) R.Pi.4 8gig ram setups
and send them to the devs WE all decide on. Let's us start compiling up 
the codes, keep it simple (for now) and implement them with gentoo-users 
as the testers of the email services.


These discussions should be continued to everyone's benefit. However 
there are way more than (3) folks on these threads who are most capable 
to do this community prototyping. If WE do not act and get hundreds of 
these deployed, email, as we know it via RFCS and other standards may 
just disappeaar, or be relegated to the far reaches of the Internet. 
What I have read, is standards based email services, particularly by 
small organizations, are under extreme pressure by large corporations to 
be marginalized out of existence.

So any of the folks in these treads can announce publically, or send me 
private email as to your concerns. Public is best, but, I understand the 
needs for private communications sometimes. So yea, I'll personally 
finaces, at least 6 months of (3) projects.
I'll take all input, but will make my (funding) decision, in a focus, 
quick strategy.

James Horton, pe