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

[Caveman Al Toraboran]

thanks.  highly appreciate your time.  to save
space i'll skip parts where i fully agree
with/happily-learned.

(e.g. loop detection; good reminder, i wasn't
thinking about it.  plus didn't know of acronyms
DSN, MDNs, etc; nice keywords for further
googing).

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, August 21, 2020 8:59 PM, Grant Taylor <gtaylor@×××××××××××××××××××××.net> wrote:

> 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.

i was thinking (and still) if such relay-by-relay
delivery increases probability of error by a
factor of n (n = number of relays in the middle).
e.g. probability of accidental silent mail loss is
if one, or more, accidentally said "yes got it!"
but actually didn't.  i.e.:

    Pr(silent loss) =

        sum_{k=1}^n
            {n choose k}
            * Pr(mistake)**k
            * Pr(no mistake)**{n-k}

    n  = number of relays in the middle.
    *  = mult.
    ** = exponent.

i wonder if it would be better if only the entry
relay aims at the confirmation from the terminal
server?  this way we won't need to assume that
relays in the middle are honouring their guarantees,
hence the probability above would be smaller since
k is limited up to 2 despite n's growth.


> 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.

care to point part of the rfc that defines "safe"
commit to disk?  e.g. how far does the rfc expect
us to go?  should we execute `sync`'s equivalent
to ensure that data is actually written on disk
and is not in operating system's file system write
buffer?


> 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.

onion signatures?  e.g. message is wrapped around
several layers of signatures for every relay in
the path?


> > this way we can have group-level rules.
>
> I'm not quite sure what you mean by group-level rules in this context.

e.g. whitelisting, tagging, spam filtration,
prioritizing, etc, based on entities that
onion-signed the message.