Re: TLS client certificates and auth external
Viktor Dukhovni wrote in <20200825182533.gw37...@straasha.imrryr.org>: |On Tue, Aug 25, 2020 at 07:06:29PM +0200, Steffen Nurpmeso wrote: | |>|because: |>| |>|1. The server indicated support for SASL in its EHLO response. |>|2. The client chose to perform SASL auth. |>| |>|If you want clients to skip SASL auth, configure them to not use |>|SASL auth (no passwords, no EXTERNAL, just a client cert). |> |> That does not work. Oh. Yes, it does! | |Naturally... Heh. |>|The protocol flow is: |> ... |>| 250 AUTH PLAIN GSSAPI ... |>|C: !!! chooses to perform or skip SASL !!! |>|--- possible SASL handshake here --- |> |> Yes, but, you know, _if_ the server announces AUTH then of course |> any automatic software will choose AUTH! Because, why would the |> server announce AUTH if it would not need it? | |Because it is advertising a *capability* not a mandate. Lots of |servers advertise AUTH even when only some clients need to or |choose to use AUTH. Of course you can always set up a dedicated |MSA on some IP:port combination which only accepts client certs, |and is configured to NOT offer AUTH. That's your choice. Usually you be given a username and a password, and a server name and a port. That you enter into the MUA, and the rest you do not know. (Unless you use a real primitive MUA, where you have to be explicit.) And for the basic MUA i maintain one could read already in the year 2004 (!) smtp-auth Sets the SMTP authentication method. If set to `login', or if unset and both smtp-auth-user and smtp-auth-password are set, AUTH LOGIN is used. If set to `cram-md5', AUTH CRAM-MD5 is used. Otherwise, no SMTP authentication is performed. smtp-auth-password Sets the global password for SMTP AUTH. Both user and password have to be given for AUTH LOGIN and AUTH CRAM-MD5. smtp-auth-user Sets the global user name for SMTP AUTH. Both user and password have to be given for AUTH LOGIN and AUTH CRAM-MD5. (plus omitted specializations). And in 2007 it had changed to smtp-auth Sets the SMTP authentication method. If set to `login', or if unset and smtp-auth-user is set, AUTH LOGIN is used. If set to `cram-md5', AUTH CRAM-MD5 is used; if set to `plain', AUTH PLAIN is used. Otherwise, no SMTP authentication is performed. I personally have _never_ send a mail via a smarthost without having authenticated myself. |And for a client to initiate SASL AUTH it has to be configured with |suitable credentials, and told to use them with the server in question. Yes. At least the former, the latter is then always automatic as of my experience. |Clients don't (implementation incompetence aside) just automatically |send their passwords to some random server that happens to include |"AUTH" in its EHLO response. I am only talking MUA here. So please replace the "client" as above with the word "mail user agent", or also simple MTAs like DMA or msmtp. You define a smarthost to contact, and if so (at least DMA can also send mail directly to a receiver instead), a login is performed. |> This does not make sense! | |It makes sense to me. You intuition is misleading you in various |non-productive directions. Try to set some preconceptions aside |and take in a new perspective. This is very tough. But maybe we have a notational problem only, where my "client" is a MUA, wheras your "client" is any SMTP aware software which transports a message to a SMTP server. |>|The relative order of the relay and recipient restrictions is somewhat |>|in flux at the moment, it changed in Postfix 3.3, but the docs have |> |> (Must be that, then.) | |No, that's just a pedantic side comment, not relevant to your situation, |needed only to avoid a small inaccuracy. So i withdraw politely in silence. Good Evening, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Concept for policy service and filtering.
Okey, i think i got an idea of what i have to do now! :) Thank you again for the advises. On Tue, Aug 25, 2020 at 6:51 PM Wietse Venema wrote: > Manuel Mely: > > In a nutshell: use the policy access server for basic rules and actions > at > > first, and only if the ruleset gets > > complicated with content filtering, return a "FILTER" action in the > server, > > and continue filtering > > with a milter? Probably i will have then to double check the matching > > rules, which is not nice. Or is it > > possible to pass, for example an identifier (matched rule uuid) to the > > milter? > > A policy server can return a PREPEND action to set a message header > that can be examined down-stream. Returning a FILTER action is also > possible, but you can't do that in the same action as PREPEND. Maybe > you can do it as an end-of-data action. > > Of course anyone else can also PREPEND headers before sending you > email, so be careful with that. > > Wietse >
Re: TLS client certificates and auth external
On Tue, Aug 25, 2020 at 07:06:29PM +0200, Steffen Nurpmeso wrote: > |because: > | > |1. The server indicated support for SASL in its EHLO response. > |2. The client chose to perform SASL auth. > | > |If you want clients to skip SASL auth, configure them to not use > |SASL auth (no passwords, no EXTERNAL, just a client cert). > > That does not work. Oh. Yes, it does! Naturally... > |The protocol flow is: > ... > | 250 AUTH PLAIN GSSAPI ... > |C: !!! chooses to perform or skip SASL !!! > |--- possible SASL handshake here --- > > Yes, but, you know, _if_ the server announces AUTH then of course > any automatic software will choose AUTH! Because, why would the > server announce AUTH if it would not need it? Because it is advertising a *capability* not a mandate. Lots of servers advertise AUTH even when only some clients need to or choose to use AUTH. Of course you can always set up a dedicated MSA on some IP:port combination which only accepts client certs, and is configured to NOT offer AUTH. That's your choice. And for a client to initiate SASL AUTH it has to be configured with suitable credentials, and told to use them with the server in question. Clients don't (implementation incompetence aside) just automatically send their passwords to some random server that happens to include "AUTH" in its EHLO response. > This does not make sense! It makes sense to me. You intuition is misleading you in various non-productive directions. Try to set some preconceptions aside and take in a new perspective. > |The relative order of the relay and recipient restrictions is somewhat > |in flux at the moment, it changed in Postfix 3.3, but the docs have > > (Must be that, then.) No, that's just a pedantic side comment, not relevant to your situation, needed only to avoid a small inaccuracy. -- Viktor.
Re: more recipients on the same relay server with smtp auth
Wietse, Viktor, Thanks for your kind answer. It seems a bit difficult but I'll try to understand and apply it. This request (redirect emails of certain domains to 3rd party mail providers with auth) can't be denied because we are moving from commercial mail security appliance to postfix and this feature is already provided to customers. (TBH I don't know how the current appliance is processing such things under the hood.) Thanks again, Zsombor Idézet (Viktor Dukhovni ): On Mon, Aug 24, 2020 at 09:35:51AM -0400, Wietse Venema wrote: > Some of our customers wanted us to forward all emails sent to some > recipient domains to 3rd party relay servers instead of the mail > server defined in the recipient domain's MX records. > > Also they provided smtp username and password for these relay servers. > > I.e. > - *@foo1.bar is sent to mailprovider-X.com with foo1user + foo1pass > - *@foo2.bar is sent to mailprovider-Y.com with foo2user + foo2pass > - etc. If these email messages are sent by your customers, you need: - In master.cf, one dedicated Postfix SMTP client per customer, with its own "-o smtp_sasl_passwd_maps=maptype:mapname" setting with that customer's login information for the remote servers. smtp-custxxx unix - - - - - smtp -o smtp_sasl_passwd_maps==hash:/etc/postfix/sasl-custxxx - In main.cf, "smtp_sender_dependent_default_transport_maps = maptype:mapname", and use that table select the dedicated Postfix SMTP client for each customer. And also SASL auth, with reject_known_sender_login_mismatch or similar, so that nobody else can impersonate these customers. This ensures that the right customer's login is used with the right renote SMTP server, and only for email sent by that customer. Given authentication of the customer's credentials *and* envelope sender address. This can be a difficult combination of things to get right. Caution is highly recommended, and perhaps best to not offer the feature at all. The risk/reward ratio may not be high enough. -- Viktor.
Re: TLS client certificates and auth external
Viktor Dukhovni wrote in <20200825160538.gt37...@straasha.imrryr.org>: |On Tue, Aug 25, 2020 at 04:56:26PM +0200, Steffen Nurpmeso wrote: |> Emmanuel Fusté wrote in |> : |>|Le 24/08/2020 à 21:14, Steffen Nurpmeso a écrit : |>|> Something else, maybe. |>|> I do not understand why my (stupid) config |>|> |>|>smtpd_sender_restrictions = |>|>check_ccert_access hash:/etc/postfix/relay_clientcert, |>|>permit_tls_clientcerts, |>|>reject_unknown_sender_domain, |>|> #reject_sender_login_mismatch, |>|>permit_sasl_authenticated, |>|> reject |>|> |>|> succeeds only if reject_sender_login_mismatch is commented out |>|> _unless_ i pass a valid client certificate. I.e., even if |>|> anything is ok except for with/out client certificate: |> |>|Just for this part : what is your content of the map configured by |>|smtpd_sender_login_maps ? |> |> I am confused. That makes no sense. To reiterate, if i pass |> a valid client certificate check_ccert_access matches, the rest of |> the chain is skipped, but SASL authentication is still performed, |> permit_sasl_authenticated still matters! If i do not pass a valid |> client certificate, reject_sender_login_mismatch triggers because |> .. but the map is empty! Also for this test the order of the |> chain cannot matter, because SASL authentication happens later. |> Whatever. Note the error happens after authentication was |> reported as being successful. | |What you're actually confused about has little to do with client certs |and to some extent SASL. | |First and foremost you need to understand that a "permit" action in the |sender restrictions is NOT final, it just short-circuits the *sender* |restrictions, the rest of restrictions, and in particular the "relay" |and "recipient" restrictions are still processed. I have to think about that. These at least do not include SASL. |Therefore, the "check_ccert_access" you actually care about is the one |in "smtpd_relay_restrictions" and/or "smtpd_recipient_restrictions". That is only as above. :) |Your other point of confusion is that you're imagining that the |restriction processing determines the SMTP protocol control flow, such |that SASL authentication only happens when "permit_sasl_authenticated" |or similar is evaluated. | |In fact, by the time (especially smtpd_delay_reject=yes, the strongly |recommended default) that the restriction processing is happening, the Ah! |SASL authentication handshake is long in the past. It happens Indeed. |because: | |1. The server indicated support for SASL in its EHLO response. |2. The client chose to perform SASL auth. | |If you want clients to skip SASL auth, configure them to not use |SASL auth (no passwords, no EXTERNAL, just a client cert). That does not work. Oh. Yes, it does! ? set smtp-config=-auth ? mail root@localhost ... s-nail: >>> STARTTLS s-nail: >>> SERVER: 220 2.0.0 Ready to start TLS s-nail: TLS: applying config: MinProtocol = TLSv1.3 s-nail: TLS: applying config: Certificate = /tmp/kdcc.pem s-nail: TLS: applying config: PrivateKey = /tmp/kdck.pem ... s-nail: >>> EHLO kdc.localdomain ... s-nail: >>> SERVER: 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 XOAUTH2 OAUTHBEARER EXTERNAL GSSAPI ... s-nail: *smtp-config*: using pipelining extension s-nail: >>> MAIL FROM: s-nail: >>> RCPT TO: s-nail: >>> DATA s-nail: >>> SERVER: 250 2.1.0 Ok s-nail: >>> SERVER: 250 2.1.5 Ok s-nail: >>> SERVER: 354 End data with . ... s-nail: >>> QUIT s-nail: >>> SERVER: 250 2.0.0 Ok: queued as E076C40547 |The protocol flow is: ... | 250 AUTH PLAIN GSSAPI ... |C: !!! chooses to perform or skip SASL !!! |--- possible SASL handshake here --- Yes, but, you know, _if_ the server announces AUTH then of course any automatic software will choose AUTH! Because, why would the server announce AUTH if it would not need it? This does not make sense! There are clients which do not even allow users to fine-tune the authentication mechanism which is used! In fact, last years thread on this ML caused that widely used MUA (i have forgotten) to actually implement that possibility!! (The lengthy bugzilla or whatever forum threads will show this. Thinkable also that the respective people are (still) on this list and read this even.) I would presume that the _sole_ reason why postfix have had no(t much bigger) problems with EXTERNAL SASL is that it is likely that EXTERNAL is not chosen automatically. This is what my MUA will do with the next minor release auth Authentication (RFC 4954) allows account credentials to be passed. This word disables all authentication mechanisms, but enables only those which can be managed automatically without external help; for example GSSAPI requires an exter‐ nally granted ticket to exist, and is therefore excluded by the default automatic selection,
Re: Concept for policy service and filtering.
Manuel Mely: > In a nutshell: use the policy access server for basic rules and actions at > first, and only if the ruleset gets > complicated with content filtering, return a "FILTER" action in the server, > and continue filtering > with a milter? Probably i will have then to double check the matching > rules, which is not nice. Or is it > possible to pass, for example an identifier (matched rule uuid) to the > milter? A policy server can return a PREPEND action to set a message header that can be examined down-stream. Returning a FILTER action is also possible, but you can't do that in the same action as PREPEND. Maybe you can do it as an end-of-data action. Of course anyone else can also PREPEND headers before sending you email, so be careful with that. Wietse
Re: TLS client certificates and auth external
Viktor Dukhovni wrote in <20200825161847.gu37...@straasha.imrryr.org>: |On Tue, Aug 25, 2020 at 05:56:41PM +0200, Steffen Nurpmeso wrote: |You have still now answered Wietse's question. If you were to do |"EXTERNAL" auth, what determines whether a user presented a valid |credential, and what part of the certificate determines the associated |login name? Who is authorised to assert such login names. | |You need to be careful to not inadvertently authorise every CA on the |planet to assert login credentials on your server. Avoiding this takes |some care. But no, i have done so from the very start? Or i do not understand what you mean. Postfix is the one that validates the client certificate the same way it does now. And it passes the necessary information to the SASL auth server so that the announced EXTERNAL SASL mechanism can actually truly be used, and succeeds. At the moment, if check_ccert_access is used, and SASL is, too, two entirely distinct logins are thinkable, no? Isn't that a much bigger mess? Than just allowing EXTERNAL and let the commonName of the certificate be of any value. I do not understand. This is how it is done?? |As I said before, instead of sending patches, if you want to see |new functionality in Postfix, please post a clear set of written |requirements and a proposed design (if you want to propose one). And as i said before, all i could imagine is that the dovecot SASL auth is improved, so that a fingerprint digest is exchanged, and an actual fingerprint is passed. But for postfix this likely does not change the situation even then, because all the different sorts of client certificate checkings surely will not go away. And you do have at least check_ccert_access as well as permit_tls_clientcerts+relay_clientcerts possibilities, do you? What is actually wrong? I do not propose anything, it is you who have at least two different client certificate mechanisms _plus_ SASL, which is inspected _in addition_ for at least the check_ccert_access that i have configured correctly? Correct? If so, where is the problem of allowing dovecot to use the data of the verified client certificate? --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Concept for policy service and filtering.
Thanks for your instant reply Wietse. Postfwd looks like a great tool, but i think it wont fit well in my requirements. For example, it is all file based configurations. Even when i could replicate the files to all nodes, I would prefer to store the rules and actions in a DB as those are created on demand and easily replicated to all postfix instances (which does not have a fixed amount). Also i am afraid of, in case i want to extend functionalities in the future, if postfwd will support it. Also rust runs fast and smooth, so i guess it will be very performant. :) About the milter, i'm going to read a little bit more. I used to know how it works, but since long time i'm not system administrator anymore :) But, apart of spam & virus filtering systems, is the previous idea more less well? In a nutshell: use the policy access server for basic rules and actions at first, and only if the ruleset gets complicated with content filtering, return a "FILTER" action in the server, and continue filtering with a milter? Probably i will have then to double check the matching rules, which is not nice. Or is it possible to pass, for example an identifier (matched rule uuid) to the milter? Greetings and again thanks for your reply! On Tue, Aug 25, 2020 at 5:31 PM Wietse Venema wrote: > Manuel Mely: > > Hi there, > > > > I?m at the moment in the concept stage for the implementation of custom > > policies which will be attached to several postfix instances. > > > > A brief description of what i have now: > > > > I have three postgres tables: mail_filter, mail_filter_rule and > > mail_filter_action > > > > a filter (mail_filter entry) can have one or many rules (mail_filter_rule > > entries) as well as actions (mail_filter_action entries) > > > > For example, > > > > Filter 1, could be something like, mail from: f...@bar.org and rcpt to: > > b...@foo.org and in this time frame 14:00-19:00 could be (and now come > the > > actions in to play), "blocked" > > There is prior art in postfwd (www.postfwd.org) for inspecting SMTP > and blocking commands. > > > Filter 2, could be something like, mail from: domainX.com and rcpt to: > > b...@foo.org and in this time frame 10:00-13:00 could be "remove > attachments > > of mime type Y and notify someone" > > If you want to inspect/modify content in addition to inspecting > SMTP commands, then that may be better done with a Milter, as Postfix > intentionally no significant content modification primitives built-in. > Milter protocol implementations exist for many languages. > > Wietse >
Re: TLS client certificates and auth external
On Tue, Aug 25, 2020 at 05:56:41PM +0200, Steffen Nurpmeso wrote: > Twenty years ago i was an angry young man because the new German > passports did not include S/MIME++ certificates and PGP keys, > signed by the German government. In the meantime the > "Bundesdruckerei" (which has become more or less private until > then, what a mess, in my opinion) actually acts as a certificate > authority. TL;DR, OAUTH is a complex mess. Its main effect is to discourage use of your own mail client, so you use WebMail, or some "app" on a mobile device. Its security is worse than passwords, especially for users who know how to manage passwords. But perhaps for sufficiently clueless users the password is less likely to be sent insecurely or to the wrong party. It is shoddy tech, optimised for the unwashed masses. > |as long as their certificate contains an email address that matches > |smtpd_sender_login_maps? > > Oh, sorry, i am not an administrator. I have read the postfix > documentation once in 2015, to setup my server VM. Until then > only externally managed accounts. And the server does not support > any login mechanism at all, the message enters the postfix there > via ssh and sendmail. That is enough for me. (It even drives > mailing lists, but that via aliases.) You have still now answered Wietse's question. If you were to do "EXTERNAL" auth, what determines whether a user presented a valid credential, and what part of the certificate determines the associated login name? Who is authorised to assert such login names. You need to be careful to not inadvertently authorise every CA on the planet to assert login credentials on your server. Avoiding this takes some care. As I said before, instead of sending patches, if you want to see new functionality in Postfix, please post a clear set of written requirements and a proposed design (if you want to propose one). -- Viktor.
Re: TLS client certificates and auth external
On Tue, Aug 25, 2020 at 04:56:26PM +0200, Steffen Nurpmeso wrote: > Emmanuel Fusté wrote in > : > |Le 24/08/2020 à 21:14, Steffen Nurpmeso a écrit : > |> Something else, maybe. > |> I do not understand why my (stupid) config > |> > |>smtpd_sender_restrictions = > |>check_ccert_access hash:/etc/postfix/relay_clientcert, > |>permit_tls_clientcerts, > |>reject_unknown_sender_domain, > |> #reject_sender_login_mismatch, > |>permit_sasl_authenticated, > |> reject > |> > |> succeeds only if reject_sender_login_mismatch is commented out > |> _unless_ i pass a valid client certificate. I.e., even if > |> anything is ok except for with/out client certificate: > > |Just for this part : what is your content of the map configured by > |smtpd_sender_login_maps ? > > I am confused. That makes no sense. To reiterate, if i pass > a valid client certificate check_ccert_access matches, the rest of > the chain is skipped, but SASL authentication is still performed, > permit_sasl_authenticated still matters! If i do not pass a valid > client certificate, reject_sender_login_mismatch triggers because > .. but the map is empty! Also for this test the order of the > chain cannot matter, because SASL authentication happens later. > Whatever. Note the error happens after authentication was > reported as being successful. What you're actually confused about has little to do with client certs and to some extent SASL. First and foremost you need to understand that a "permit" action in the sender restrictions is NOT final, it just short-circuits the *sender* restrictions, the rest of restrictions, and in particular the "relay" and "recipient" restrictions are still processed. Therefore, the "check_ccert_access" you actually care about is the one in "smtpd_relay_restrictions" and/or "smtpd_recipient_restrictions". Your other point of confusion is that you're imagining that the restriction processing determines the SMTP protocol control flow, such that SASL authentication only happens when "permit_sasl_authenticated" or similar is evaluated. In fact, by the time (especially smtpd_delay_reject=yes, the strongly recommended default) that the restriction processing is happening, the SASL authentication handshake is long in the past. It happens because: 1. The server indicated support for SASL in its EHLO response. 2. The client chose to perform SASL auth. If you want clients to skip SASL auth, configure them to not use SASL auth (no passwords, no EXTERNAL, just a client cert). The protocol flow is: C: SYN S: SYN-ACK C: ACK S: 220 greeting C: EHLO S: 250- ... 250 STARTTLS C: STARTTLS S: 250 make my day... C: TLS client hello S: TLS server hello : ... sound and fury of TLS handshake ... Channel is now TLS encrypted C: 250 EHLO S: 250- ... 250 AUTH PLAIN GSSAPI ... C: !!! chooses to perform or skip SASL !!! --- possible SASL handshake here --- C: MAIL FROM: BODY=8BITMIME SIZE=... S: 250-OK C: RCPT TO: ORCPT=... S: --- evaluates *ALL* restrictions here! --- client restrictions -- might look at cert or SASL login helo restrictions -- might look at cert or SASL login sender restrictions -- might look at cert or SASL login recipient restrictions -- might look at cert or SASL login relay restrictions -- might look at cert or SASL login S: 250 OK (or 5XX go spam someone else) C: DATA S: evaluates data restrictions here -- might look at cert or SASL login 354 Go ahead (or 5XX go spam someone else) C: . S: evaluates end of data restrictions here -- might look at cert or SASL login S: 250 OK (or 5XX go spam someone else) C: QUIT S: 221 Goodbye With this in mind, you'll have an easier time to understand where SASL and client certs fit into the picture. The relative order of the relay and recipient restrictions is somewhat in flux at the moment, it changed in Postfix 3.3, but the docs have not caught up, and I hope it will change again 3.6, provided you set the compatibility level high enough. But this is unlikely to matter terribly much in most cases. -- Viktor.
Re: TLS client certificates and auth external
Hello.
Wietse Venema wrote in
<4bbwrb5qbbzj...@spike.porcupine.org>:
|What is the trust model: can anyone send email as long as they have
|a valid certificate that is signed by one of hundreds of CAs, and
I am a political person and can only response to this politically.
Other than that i do not know, Wietse Venema.
Twenty years ago i was an angry young man because the new German
passports did not include S/MIME++ certificates and PGP keys,
signed by the German government. In the meantime the
"Bundesdruckerei" (which has become more or less private until
then, what a mess, in my opinion) actually acts as a certificate
authority.
The IETF pushes per-DNS-zone authorities. DNS can now go over
encrypted transport, and the content itself is also (though
differently, unfortunately) cryptographically verifiable, if the
zone does that.
The Internet of Things produces devices which want to call home
and take part in the internet. If you buy a light bulb today it
may want to contact home when you use it first in five years from
now on.
The past has shown passports are important, i also say this in
particular as a German (others could chime in of course), people
even kill for passports eventually. I do not see a particular
difference in between digital and paper passports.
I know for sure however that with client certificates there is
a little bit of security and affirmation where otherwise there is
nothing. My MUA for example was treated as a lesser secure
application by a big free mail provider, because it does not use
OAuth. Even though my password is in an encrypted .netrc file,
and that in turn exists on an encrypted partition on an
unencrypted block device (and also that will change in the
future). The partition is unmounted on lid close. The data
transport is secured via TLS. Why is this lesser secure?
Especially since XOAUTH2 / OAUTHBEARER is not lesser secure.
But in how far is that different than just offering the
possibility to specify per-application passwords, for example.
I.e., diversify that, do not use the account master password for
logins via SMTP / POP3 / IMAP?
And then i have to go over HTTPS to refresh my temporary password.
Why is that necessary, the XOAUTH2 / OAUTHBEARER JSON hashmasp
used during login could very well be used to update refresh tokens
on the fly, too. Maybe in the future there will be advertisements
when updating the token, i do not know.
I cannot time out this token, different to Kerberos/GSSAPI, where
my local kdestroy(1) program can be used to disable the ticket.
With client certificates people are, or could be, responsible
themselves. We have programs like GPG agent and ssh-agent, there
are USB sticks like yubikey and such, which help in storing their
private counterparts securely (unless the scene is getting real
tough, at least, but this cannot be helped anyhow, i would say).
Their content is standardized, the algorithms are standardized and
well-tested, and open for any mathematician / cryptographer who is
dedicated enough to go for it. This is as good as it can get.
|as long as their certificate contains an email address that matches
|smtpd_sender_login_maps?
Oh, sorry, i am not an administrator. I have read the postfix
documentation once in 2015, to setup my server VM. Until then
only externally managed accounts. And the server does not support
any login mechanism at all, the message enters the postfix there
via ssh and sendmail. That is enough for me. (It even drives
mailing lists, but that via aliases.)
But in the meantime i have become conscious that this login-test
setup is totally broken, i am already reading the documentation
anew in another window.
Thank you!
By the way, there is a little improvement in the patch:
diff --git a/src/xsasl/xsasl_dovecot_server.c
b/src/xsasl/xsasl_dovecot_server.c
-index 601f787..9b849b4 100644
+index 601f787..780fd91 100644
--- a/src/xsasl/xsasl_dovecot_server.c
+++ b/src/xsasl/xsasl_dovecot_server.c
@@ -166,7 +166,8 @@ typedef struct {
@@ -98,8 +97,8 @@ index 601f787..9b849b4 100644
server->mechanism_argv = 0;
-server->tls_flag = args->tls_flag;
+server->tls_flags = args->tls_flags;
-+server->tls_cert_username = (args->tls_flags && args->tls_cert_username)
-+ ? mystrdup(args->tls_cert_username) : 0;
++server->tls_cert_username = ((args->tls_flags & XSASL_TLS_CLIENT_CERT)
++ && args->tls_cert_username) ? mystrdup(args->tls_cert_username) : 0;
It does not really fix a bug, but is more explicit. (I have not
compiled this, i only recognized it would be more explicit like
this.) I will attach this version, ok?
| Wietse
--End of <4bbwrb5qbbzj...@spike.porcupine.org>
Ciao, Mr. Venema,
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
diff --git a/src/smtpd/smtpd_sasl_glue.c
Re: Concept for policy service and filtering.
Manuel Mely: > Hi there, > > I?m at the moment in the concept stage for the implementation of custom > policies which will be attached to several postfix instances. > > A brief description of what i have now: > > I have three postgres tables: mail_filter, mail_filter_rule and > mail_filter_action > > a filter (mail_filter entry) can have one or many rules (mail_filter_rule > entries) as well as actions (mail_filter_action entries) > > For example, > > Filter 1, could be something like, mail from: f...@bar.org and rcpt to: > b...@foo.org and in this time frame 14:00-19:00 could be (and now come the > actions in to play), "blocked" There is prior art in postfwd (www.postfwd.org) for inspecting SMTP and blocking commands. > Filter 2, could be something like, mail from: domainX.com and rcpt to: > b...@foo.org and in this time frame 10:00-13:00 could be "remove attachments > of mime type Y and notify someone" If you want to inspect/modify content in addition to inspecting SMTP commands, then that may be better done with a Milter, as Postfix intentionally no significant content modification primitives built-in. Milter protocol implementations exist for many languages. Wietse
Concept for policy service and filtering.
Hi there, I’m at the moment in the concept stage for the implementation of custom policies which will be attached to several postfix instances. A brief description of what i have now: I have three postgres tables: mail_filter, mail_filter_rule and mail_filter_action a filter (mail_filter entry) can have one or many rules (mail_filter_rule entries) as well as actions (mail_filter_action entries) For example, Filter 1, could be something like, mail from: f...@bar.org and rcpt to: b...@foo.org and in this time frame 14:00-19:00 could be (and now come the actions in to play), "blocked" Filter 2, could be something like, mail from: domainX.com and rcpt to: b...@foo.org and in this time frame 10:00-13:00 could be "remove attachments of mime type Y and notify someone" I developed a small policy server [1] in rust, and at the moment the concept is working fine for actions like accepting, rejecting or even bcc at the SMTP protocol stage (i am using in at smtpd_recipient_restrictions). Normal, is how [1] works, you have to return only one action. But there are some other rules which must be checked in another stage, i would say with a after-queue content filter [2]. Rules are very flexible, but maybe most of them will have only one action reject or accept, that's why, i find better to do it at the SMTP protocol stage. Then, only If a rule contains some content filtering related action, i could return a "FILTER" action as stated here[3] and then a custom content filter will finish the job. I hope i am on the right way, if someone have some other thoughts i would be glad to read them. :) Best regards, Manuel Mely 1- http://www.postfix.org/SMTPD_POLICY_README.html 2- http://www.postfix.org/FILTER_README.html 3- http://www.postfix.org/access.5.html
Re: TLS client certificates and auth external
Emmanuel Fusté wrote in : |Le 24/08/2020 à 21:14, Steffen Nurpmeso a écrit : |> Something else, maybe. |> I do not understand why my (stupid) config |> |>smtpd_sender_restrictions = |>check_ccert_access hash:/etc/postfix/relay_clientcert, |>permit_tls_clientcerts, |>reject_unknown_sender_domain, |> #reject_sender_login_mismatch, |>permit_sasl_authenticated, |> reject |> |> succeeds only if reject_sender_login_mismatch is commented out |> _unless_ i pass a valid client certificate. I.e., even if |> anything is ok except for with/out client certificate: |Just for this part : what is your content of the map configured by |smtpd_sender_login_maps ? Nothing. ;) Hm. I think i have misread the documentation anyhow, this is totally false: i have also thought that check_ccert_access is used to enable permit_tls_clientcerts. Hm. I have to reread it all, i did so first and last in 2015, for my server VM, and that is simple, allows no logins at all! Thanks for pointing this out. I think i have real shortcomings understanding the syntax above, actually. I thought the above is worked sequentially, and some actions are "insertions", for example there is "sleep SECONDS", which is then performed when walking the chain of tests, at the very position of the chain, in place. I thought this check_ccert_access is like that, too, loading the according DB, to enable permit_tls_clientcerts. Obviously wrong. So the check_ccert_access check makes the test login succeed when there is a client certificate, the remains of the chain are not evaluated at all, but the SASL login is then performed as a totally different step because i have smtpd_sasl_auth_enable? This has nothing to do with the permit_sasl_authenticated in the chain above, thus. But no, here smtpd_sasl_auth_enable is used to enable permit_sasl_authenticated in chains, says the documentation. I am confused. That makes no sense. To reiterate, if i pass a valid client certificate check_ccert_access matches, the rest of the chain is skipped, but SASL authentication is still performed, permit_sasl_authenticated still matters! If i do not pass a valid client certificate, reject_sender_login_mismatch triggers because .. but the map is empty! Also for this test the order of the chain cannot matter, because SASL authentication happens later. Whatever. Note the error happens after authentication was reported as being successful. I better go now. :) I really have to try out reject_unauth_pipelining. Hm! |Emmanuel. Au revoir. --End of --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: TLS client certificates and auth external
What is the trust model: can anyone send email as long as they have a valid certificate that is signed by one of hundreds of CAs, and as long as their certificate contains an email address that matches smtpd_sender_login_maps? Wietse
Re: TLS client certificates and auth external
Le 24/08/2020 à 21:14, Steffen Nurpmeso a écrit : Something else, maybe. I do not understand why my (stupid) config smtpd_sender_restrictions = check_ccert_access hash:/etc/postfix/relay_clientcert, permit_tls_clientcerts, reject_unknown_sender_domain, #reject_sender_login_mismatch, permit_sasl_authenticated, reject succeeds only if reject_sender_login_mismatch is commented out _unless_ i pass a valid client certificate. I.e., even if anything is ok except for with/out client certificate: Just for this part : what is your content of the map configured by smtpd_sender_login_maps ? Emmanuel.
