On Tuesday 24 November 2009 18:39:34 Victor Duchovni wrote: > > 3) server only sends relayed mail to not-on-server address if its from > > authenticated client (with the expected certificate); > > mynetworks = 127.0.0.1 > relay_domains = > smtpd_recipient_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > reject_unauth_destination > ... UCE checks ...
Thanks Viktor! No TLS authentication can do that? I was reading about SASL, but still had no clear idea why/where its necessary? Perhaps you know some how-to or search keywords for this case (point 3), as there appear to be more to ask? > > 6) before accepting message, server checks clients authenticity in > > similar way, if user U is the source. > > You are trying to impose an end-to-end security model (end-user > entitlements to send email, ...) onto a hop-by-hop infrastructure > (Internet email). Simply put, I just wouldn't like anyone ever to send out mail as myself and get archived automatically on server as if it was actually me, who sends - put on such a barrier was my intention. Well, maybe a bit silly. But doesn't it allow end-to-end authentication as a special case? Anyway, this is the part "too much", right? > Generally, you can't impose a naive user authentication policy onto a > hop-by-hop store-and-forward infrastructure, because the party forwarding > a message is often not the original user who injected into the mail system. > This is not a "Postfix" limitation, is it a fundamental part of Internet > email architecure. > > If your MTA is in fact an "MSA" and only accepts mail (typically on > port 587), directly from an MUA operated by the end-user, with no > local submission by authorized users via the command-line on authorized > null client systems that forward to your server, or other indirect > submission mechanisms, ... Then and only then, can you impose strong > user authentication, unless you want to force S/MIME onto all the MUAs, > and check end-to-end message signatures, ... > > Postfix does support obtaining client certificates, but has no support > for directly associating these with a particular sender. We don't have > an analogue of reject_sender_login_mismatch (sender <-> SASL identity > mapping) for TLS client certs. Such a mapping can be implemented in a > "policy service" or milter. > > -- > Viktor.
signature.asc
Description: This is a digitally signed message part.
