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

[Grant Taylor]

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