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
