1 |
On 8/21/20 11:01 AM, Caveman Al Toraboran wrote: |
2 |
> yes, i do consider re-inventing octagonal wheels. |
3 |
|
4 |
I think that it's occasionally a good thing to have a thought experiment |
5 |
about how $THING might be made better. |
6 |
|
7 |
It's probably good to have discussions around green feel types of |
8 |
replacements. |
9 |
|
10 |
But it's important to eventually assess the pros and cons of the old (as |
11 |
it exists), the new (as from green field), and the transition between |
12 |
the two. |
13 |
|
14 |
Sometimes the new doesn't warrant the transition, but it does provide an |
15 |
option that might be worth augmenting into the old. |
16 |
|
17 |
If nothing else, it's good to have the discussions and be able to answer |
18 |
why something was done or chosen to remain the same. |
19 |
|
20 |
> here, i'm just "asking" to see what makes the "safely stored" |
21 |
> guarantee. |
22 |
|
23 |
MTAs are supposed to be written such that they commit the message to |
24 |
persistent storage medium (disk) before returning an OK message to the |
25 |
sending server. |
26 |
|
27 |
There is some nebulous area around what that actually means. But the |
28 |
idea is that the receiving server believes, in good faith, that it has |
29 |
committed the message to persistent storage. Usually this involves |
30 |
writing the message to disk, probably via a buffered channel, and then |
31 |
issued system calls to ask the OS to flush the buffer to disk. |
32 |
|
33 |
Is there room for error? Probably. |
34 |
|
35 |
Had the server made (more than) reasonable effort to commit the message |
36 |
to disk? Yes. |
37 |
|
38 |
The point being, don't acknowledge receipt of the message while the |
39 |
message is only in the MTA's memory buffer. Take some steps to commit |
40 |
it to persistent storage. |
41 |
|
42 |
That being said, there are some questionable servers / configurations |
43 |
that will bypass this safety step in the name of performance. And they |
44 |
/do/ /loose/ /email/ as a negative side effect if (when) they do crash. |
45 |
This is a non-default behavior that has been explicitly chosen by the |
46 |
administrators to violate the SMTP specification. Some MTAs will log a |
47 |
warning that they are configured to violate RFCs. |
48 |
|
49 |
> got any specific definition of what makes a storage "guaranteed"? |
50 |
> e.g. what kind of tests does the mail server do in order to say "yup, |
51 |
> i can now guarantee this is stored safely!"? |
52 |
|
53 |
It's more that they do something safe (write the message to disk) |
54 |
instead of risky (only store it in memory). |
55 |
|
56 |
Everything can fail at some point. It's a matter of what and how many |
57 |
reasonable steps did you take to be safe. Read: Don't cut corners and |
58 |
do something risky. |
59 |
|
60 |
> i guess you think that i meant that a relay should be mandatory? |
61 |
|
62 |
Sending / outbound SMTP servers /are/ a relay for any messages not |
63 |
destined to the local server. |
64 |
|
65 |
There is almost always at least two SMTP servers involved in any given |
66 |
email delivery. All but the final receiving system is a relay. |
67 |
|
68 |
> (yes, a relay doesn't have to be used. i'm just describing some uses |
69 |
> of relays that i think make sense. (1) indicate trust hierarchy, (2) |
70 |
> offload mail delivery so that i can close my laptop and let the relay |
71 |
> have fun with the retries. not sure there is any other use. anyone?) |
72 |
|
73 |
There are many uses for email relays. A common one, and best practice, |
74 |
is to have an /inbound/ relay, commonly known as a backup email server. |
75 |
The idea being it can receive inbound messages while the primary email |
76 |
server is down (presumably for maintenance). |
77 |
|
78 |
Many SaaS Email Service Providers (ESPs) /are/ relay servers. They |
79 |
receive email from someone and send it to someone else. |
80 |
|
81 |
A number of email hygiene appliances function as an email relay between |
82 |
the world and your ultimate internal email server. Services that filter |
83 |
inbound email qualify here too. |
84 |
|
85 |
It is common, and I think it's best practice, to have web applications |
86 |
send email via localhost, which is usually a relay to a more capable hub |
87 |
email server which sends outbound email. Both of these layers are relays. |
88 |
|
89 |
A relay is the same thing for email that a router is for a network. |
90 |
|
91 |
|
92 |
|
93 |
-- |
94 |
Grant. . . . |
95 |
unix || die |