On 8/20/20 7:39 PM, Caveman Al Toraboran wrote:
1. receipt by final mail server (mandatory).
You're missing the point that each and every single server along the
path between the original submission server and the final destination
server is on the hook for delivery of the message -or- notification of
it's failure back to the purported sender address. So "final mail
server" is not sufficient.
Each receiving server in the chain tells the sending server a definitive
message that means "Okay, I've received the message and I will dutifully
pass it on to the next server -or- report a problem."
The RFCs defining SMTP don't consider a server crashing / power failing
/ etc. after saying "Okay..." as sufficient reason to fail to perform
the job. Even in the event of a crash / power fail, the receiving
server MUST process the email when it recovers.
Of course, there are servers that go against the RFC "MUST" directives
and either don't safely commit messages to disk /before/ saying
"Okay..." and / or don't deliver failure messages. There are still
other servers that don't accept such incoming failure notices. Both of
which are against RFC "MUST" directives and as such violating the SMTP
specification and thereby breaking interoperability. Particularly the
"trust" part there of.
These failure notifications have standardized on Delivery Status
Notification, a.k.a. DSN, and historically called a "bounce". There has
been evolution from many disparate formats of a bounce to an industry
standard DSN. Said industry standard DSN is defined in RFCs.
DSNs MUST be non-optional for failure. The only exception is if the
sending system uses an extra option to specify that a DSN should /not/
be sent in the event of a failure. Receiving systems are compelled to
send DSNs in the absence of said option.
2. receipt by end user(s) (optional).
3. opening by end user(s) (optional).
These notifications are generally considered to be Message Disposition
Notifications, and are optional. Further, the client is what sends MDNs
/if/ it chooses to do so. MDNs are even more unreliable than DSNs.
(1) is required by the server, else mail will be retransmitted from
source relay(s) (or client if done directly). (2) is optional by
final server, (3) is optional by end user's client.
#1 is generated by RFC compliant servers. Not all servers are RFC
compliant.
#2 and #3 are generated by end user clients. Not all clients are
willing to to do so.
the job of a relay would be to optionally add some metadata
This really isn't optional.
*SOMETHING* /standard/ *MUST* be added. If for no other reason than to
detect and prevent loops.
(e.g. maybe describing sender's role) and sign the whole thing (e.g. by
company's private key).
I would suggest a /server's/ private key, and *NOT* the company's
private key. There is a HUGE difference in potential for private key
exposure. If one server is compromised, the entire company could be
crippled if the /company's/ private key is used. Conversely, if the
/server's/ private key is used, then /only/ /the/ /server/ is compromised.
It is quite possible to have the company's public key published such
that the company's internal CA can issue individual keys to each server.
Signing will be of somewhat limited value as it will quite likely be
subject to the same problem that DMARC / ARC suffer from now. Mail
servers can sign what they receive. But in doing so, they alter what is
sent to include their signature. As such, the data that the next server
receives is different. The real problem is working backwards. Down
stream servers don't have a reliable way to undo what upstream servers
have done to be able to get back to the original message to validate
signatures.
There is also the fact that various fields of the email are allowed to
have specific trivial modifications made to them, such a line wrapping
or character encoding conversion. Such changes don't alter the content
of the message, but they do alter the bit pattern of the message. These
types of changes are even more difficult to detect and unroll as part of
signature validation.
this way we can have group-level rules.
I'm not quite sure what you mean by group-level rules in this context.
--
Grant. . . .
unix || die
