Minor RFC 4954 violation
Looks like Postfix violates this MUST: The AUTH command is not permitted during a mail transaction. An AUTH command issued during a mail transaction MUST be rejected with a 503 reply. mail from: 250 2.1.0 Ok auth plain XXX 235 2.0.0 Authentication successful
Re: pipe flags vs lmtp
On 9.4.2012, at 16.25, Wietse Venema wrote: Timo Sirainen: There's a problem with aliases that LMTP server can't solve. Lets say I have two aliases: info@domain - shared@domain sales@domain - shared@domain The LMTP server sees RCPT TO:shared@domain for mails that arrive to both of them. If the sender sent the mail to only one of them, the original address can at least in theory be read from the Received: lines. If the sender sent the mail to both of these aliases, the LMTP server won't see the originating address anywhere at all. I wonder if careful use of the DSN extension would help. With DSN, the SMTP/LMTP client sends the original recipient with: RCPT TO:final-rcpt ORCPT=rfc822;orig-rcpt ... Does Postfix already send this if LMTP server advertises DSN? One problem is that DSN hands off the responsibility to notify the sender about successful delivery. I don't know if that is desirable. Not necessarily a problem, but I can't seem to find any discussion on how it should interact with Sieve. This is clear: * NOTIFY=FAILURE + Sieve discard: Don't send DSN But nothing else is. I'm guessing perhaps: * NOTIFY=SUCCESS + Sieve discard: Send a success DSN * NOTIFY=FAILURE + Sieve reject: Send a failure MDN, but no DSN * NOTIFY=SUCCESS + Sieve reject: Send a failure MDN, but no DSN * NOTIFY=FAILURE + Sieve ereject: Reject the mail on DATA reply, no DSN * NOTIFY=SUCCESS + Sieve ereject: Reject the mail on DATA reply, no DSN RET=FULL also seems like it could only be abused..
Re: pipe flags vs lmtp
On 10.4.2012, at 19.28, Wietse Venema wrote: Timo Sirainen: I wonder if careful use of the DSN extension would help. With DSN, the SMTP/LMTP client sends the original recipient with: RCPT TO:final-rcpt ORCPT=rfc822;orig-rcpt ... Does Postfix already send this if LMTP server advertises DSN? Yes :-) It's the same code for both SMTP and LMTP. OK. I guess I'll look into adding DSN support then. One problem is that DSN hands off the responsibility to notify the sender about successful delivery. I don't know if that is desirable. Not necessarily a problem, but I can't seem to find any discussion on how it should interact with Sieve. This is clear: * NOTIFY=FAILURE + Sieve discard: Don't send DSN But nothing else is. I'm guessing perhaps: * NOTIFY=SUCCESS + Sieve discard: Send a success DSN * NOTIFY=FAILURE + Sieve reject: Send a failure MDN, but no DSN * NOTIFY=SUCCESS + Sieve reject: Send a failure MDN, but no DSN * NOTIFY=FAILURE + Sieve ereject: Reject the mail on DATA reply, no DSN * NOTIFY=SUCCESS + Sieve ereject: Reject the mail on DATA reply, no DSN I think that reject/tempfail are easy - just report 5xx or 4xx at end-of-data time, and the MTA will take care of notification. ereject can do that, but reject is specified to always send MDN. How the MDN is supposed to interact with DSN is a bit unclear. I was thinking that discard and reject could maybe be treated as if the delivery was successful and that the discard/reject was more of a post-delivery client operation. Anyway, I guess I'll go and ask in Sieve mailing list what others have done. With SUCCESS, the LMTP server would be responsible for sending the notification. If the LMTP server already has the ability to forward mail, and if that code path can be reused, then sending the success notification might not cost a lot of extra code. Yes, there's already existing code for sending DSN, so should be pretty easy to add.
Re: pipe flags vs lmtp
On 9.4.2012, at 6.06, /dev/rob0 wrote: - is there a particular reason why these headers are not already an option via lmtp (aside from nobody asking for or seeing the need previously). Is there an architectural or conceptual reason why these headers should not be added via an lmtp connection? Second, it really seems more appropriate to do this in the LMTP daemon. It gets the envelope recipient for each mail and can do this (in theory) much better and more accurately than Postfix can. We don't know what the LMTP daemon is going to do with that mail ... perhaps it will be rewritten and forwarded on somehow. There's a problem with aliases that LMTP server can't solve. Lets say I have two aliases: info@domain - shared@domain sales@domain - shared@domain The LMTP server sees RCPT TO:shared@domain for mails that arrive to both of them. If the sender sent the mail to only one of them, the original address can at least in theory be read from the Received: lines. If the sender sent the mail to both of these aliases, the LMTP server won't see the originating address anywhere at all.
Re: Next day
On 4.4.2012, at 10.31, Γεώργιος Δεδούσης wrote: Wietse, please comment, don't you think that a public repo, showing each source code change would be useful for Postfix? An issue reporting system too? Issue trackers seem to be kind of a waste of time for projects with few developers: a) You get non-issues reported, which get simply resolved as NOTABUG. If it was reported in mailing list other people might have answered to it quickly and without spending the actual developers' time. Note that very few people besides the developers bother to read what happens in issue tracker, while there are a lot of people reading and answering mailing lists. b) Similarly some feature requests could be resolved with much less trouble on mailing list than in issue tracker. Even good ideas might become better with some mailing list discussion. c) Important bugs usually get fixed quickly in any case, so an issue tracker isn't very useful for them. d) Non-reproducible bugs often clutter the issue tracker. (These may not be real bugs at all.) e) Features requests wanted by about 1 person in the world often clutter the issue tracker. (I have added many of them to many bugzillas, nobody ever closes them and I doubt anyone will every implement them.) So the only useful issues for a tracker would be the ones that are important enough to get fixed/implemented when there's time, but not important enough that they actually bother all that many people. Those can be tracked manually in whatever way without much trouble. I've had some thoughts about integrating an issue tracker with a mailing list, but it hasn't advanced beyond the idea stage. http://dovecot.org/list/dovecot/2007-January/018786.html describes the idea in case someone is interested in developing it (I think there are some more details somewhere else in the mailing list as well). One interesting aspect of it is that it wouldn't necessarily require the primary developers to use it at all.
Re: Make local tempfail when LDAP is down
On Wed, 2011-04-27 at 07:19 -0400, Wietse Venema wrote: It is clear. getpwnam_r() returns 0 both on success and user not found, you just need to check if the result is NULL or not. If it returns anything else than 0 it's a transient error. If the NSS code internally messes this up, that's its fault then. But I think getpwnam_r() API is fine. Just checking: whose getpwnam_r() API are you talking about? I looked at some manpages and found that vendors have been changing their getpwnam() and getpwnam_r() error reporting semantics over time. I think the POSIX API works in all OSes commonly used nowadays. FreeBSD 5.1, NetBSD 3.0, OpenBSD 4.4, Solaris 5(?), OS X (some version), Linux for last 5+ years. I wrote some wrappers for these and people haven't complained about them much yet (just that OpenBSD had a bug): http://hg.dovecot.org/dovecot-2.0/raw-file/tip/src/lib/ipwd.c Just because a system has getpwnam_r(), that does not mean it works like your API; and on some systems, getpwnam() does report errors via errno (e.g. FreeBSD8), whereas the original UNIX getpwnam() never returned for transient errors, because all reads were from local files. Linux getpwnam() man page makes it sound like it's not a good idea to even try to check the errno after getpwnam()=NULL call.
Re: Make local tempfail when LDAP is down
On 27.4.2011, at 18.04, Wietse Venema wrote: I think the POSIX API works in all OSes commonly used nowadays. FreeBSD 5.1, NetBSD 3.0, OpenBSD 4.4, Solaris 5(?), OS X (some version), Linux for last 5+ years. I wrote some wrappers for these and people haven't complained about them much yet (just that OpenBSD had a bug): http://hg.dovecot.org/dovecot-2.0/raw-file/tip/src/lib/ipwd.c Unfortunately, lack of complaints does not prove that rare errors are handled correctly :-) Witness the bug that led to this thread, which is at least five years old. I think the original bug was probably because of the use of getpwnam(). But because its API is pretty much unfixable by now the only realistic way to fix that is by modifying Postfix to not use it. So the only problems left with replacing its use with getpwnam_r() are: a) Does the code not compile? (Can be checked automatically at compile time.) b) Does the code compile, but not actually work because of an API difference? (Is there such an OS where this isn't caught by a) ?) c) Does the code more or less randomly fail? I think in most cases where its use doesn't work it can be caught by a compiler error. If it works but somewhat randomly gives error instead of user doesn't exist it's not really any worse than the current getpwnam() interface. And I'm sure getpwnam_r() is at least somewhat tested in use by now so that a user doesn't exist won't consistently give error, so that's not a problem either. So the only problem is to get it to run and not crash/fail at startup. Since it's immediately obvious if either one of them happens, I think it's pretty safe to just do the modification and add workarounds (like a wrapper to getpwnam()) later if people start to complain. You can't make everything work in all ancient OSes anyway. SunOS POSIX as of 5.5 but requires compile-time switch Solaris 2.4 and earlier releases provided definitions of the getpwnam_r() and getpwuid_r() functions as specified in POSIX.1c Draft 6. The final POSIX.1c standard changed the interface for these functions. ... For POSIX.1c-conforming applications, the _POSIX_PTHREAD_SEMANTICS and _REENTRANT flags are automatically turned on by defining the _POSIX_C_SOURCE flag with a value =199506L. Unfortunately, setting _POSIX_C_SOURCE changes more than just this, and so should be done carefully. Yes, I definitely wouldn't want to enable it globally, that's why I added it only to one specific .c file with the wrapper functions. In any case, this code should be used only after it is verified to work. Manpages do not always describe reality. Sure. You can wait a while longer to see how Dovecot does with this change. :)
Re: Patch: support BURL
On Mon, 2010-04-12 at 11:17 -0400, Victor Duchovni wrote: I too would have expected a new IMAP extension that would allow the IMAP client to ask the IMAP server to post the message. I don't know why this route was not taken. Lemonade group discussed this in their push vs pull arguments. I didn't follow Lemonade back then, so I can't give any reasons why pull was chosen. This was anyway a conscious design decision made by the majority of people in the group. A quick google search found a draft for the push method: http://tools.ietf.org/html/draft-gellens-lemonade-push-00 My personal opinion is that: 1) BURL seems somewhat similar to how email clients already behave. They already save message to IMAP server and send it to SMTP server. BURL keeps this behavior, it just replaces DATA command with BURL (plus of course requires the client to first register the IMAP URL). 2) Embedding SMTP commands among IMAP traffic seems a bit ugly too. For just MAIL FROM and RCPT TO it's probably not too horrible, but what about (future) SMTP extensions, should they be somehow also supported? Anyway, I don't think there is much choice anymore. Either implement BURL that has at least a chance of becoming popular (and with Apple now implementing it, especially if their future clients will support it, there is some chance) or try to implement your own non-standard way that will work only in some specific random installations. signature.asc Description: This is a digitally signed message part
Re: Patch: support BURL
On Mon, 2010-04-12 at 12:13 -0400, Charles Marcus wrote: On 2010-04-12 12:03 PM, Simon Waters wrote: Some days I think starting again from scratch with software would be a good idea, then I remember how quickly I can code Timo (dovecot author) has expressed interest in maybe someday coding an IMAP client from scratch... one can only hope... ;) Not my client and not really even usable yet, but it started with the right ideas: http://trojita.flaska.net/ I could see myself continuing it instead of starting from scratch.. signature.asc Description: This is a digitally signed message part
Re: Postfix doesn't fall back on other IP addresses
On 8.3.2010, at 1.26, Wietse Venema wrote: smtp_address_preference (default: ipv6) Probably the whole reason for this thread was because of me. I used to have a working IPv6 setup, and then switched to a different ISP and just copied all my configs. Everything worked fine for a few days so I didn't think too much about it after that. Then several years later I hear Erik's having problems subscribing to Dovecot mailing list. Of course I fixed the problem immediately as I found out about it, but I'm just wondering how many other such setups there are that break once IPv6 becomes more common. Should this setting default to any? Is there really even a reason for it to be other than any (at least until IPv6 really is commonly used everywhere)?
Re: Postfix doesn't fall back on other IP addresses
On 8.3.2010, at 2.22, Wietse Venema wrote: Of course I fixed the problem immediately as I found out about it, but I'm just wondering how many other such setups there are that break once IPv6 becomes more common. Should this setting default to any? Is there really even a reason for it to be other than any (at least until IPv6 really is commonly used everywhere)? Perhaps, that's why I talked about smtp_address_preference = any on the mailing list. Yeah, just trying to give some example. Currently, Postfix ships with inet_protocols = ipv4 as the default, so people who turn on IPv6 support should know what they are doing. And when I changed it, I did know what I was doing. But a few years later I forgot about it. When switching ISP, it was obvious that I had to change my IP addresses, so I changed them in all my configs. But it was much less obvious that I had to change anything else, like remember that I had enabled IPv6 in some application that could sometimes break because of that change. That brings another thought to my mind: Maybe the default could be based on current DNS settings? If the server's primary address has IPv6 DNS record, prefer it, otherwise prefer any. (I haven't thought much yet if it's that good of an idea.) I don't know common it is to have different performance levels or different failure modes for IPv6 and IPv4. Nor do I know how common it is for destinations to have half a dozen or more IPv6 addresses (i.e. more than the default Postfix smtp_mx_address_limit of 5). Me neither. And it was fine for many years. But maybe it's soon getting worse as IPv4 address availability is disappearing.
Re: tls vs ssl
On 2.3.2010, at 9.18, Daniel L. Miller wrote: OK - I'm an idiot. I'll just admit that up front and get it out of the way. Now that that's settled, what is the difference between SSL and TLS in a MUA - particularly Thunderbird - in a Postfix context? http://wiki.dovecot.org/SSL tries to explain their difference. I would have sworn I used to use Thunderbird with SSL specified and connected to my Postfix servers fine. Now, I can only connect in TLS mode. What did I break? You no longer have smtps port enabled?
Re: Scalable
On 13.2.2010, at 0.41, Victor Duchovni wrote: No, this is largely irrelevant. What matters is the IMAP performance they expect, that IMAP servers are reasonably CPU and memory intensive. From what I've seen is that IMAP servers normally take less than 1% CPU load (mainly Dovecot, but I'd think others too). Memory is more important, currently maybe 0.5 MB/connection or so for Dovecot. Usually anyway disk IO is the bottleneck.
Re: Postfix VCS repository
On Thu, 2009-10-01 at 13:27 -0400, Wietse Venema wrote: Miguel Di Ciurcio Filho: Is there an unofficial Postfix VCS repository? I believe there is not an official one, is there a reason for that? I'm asking because I want to keep track of what is going on 2.7 development. Checking the release notes file or the change log file is not very practical. There is a collection of PGP-signed tarballs linked off the download webpage. I am not aware of a version control system that provides the integrity guarantees of PGP. Apparently both Mercurial and git support it, at least for explicitly signed revisions: http://mercurial.selenic.com/wiki/GpgExtension http://www.kernel.org/pub/software/scm/git/docs/git-tag.html I should probably try using those too. :) signature.asc Description: This is a digitally signed message part
Re: feature request: deliver to compressed files on Maildir boxes
On Sep 8, 2009, at 6:16 PM, mouss wrote: - every time I hear zlib, someting like vulnerability hits my ears. Well, you inspired me to finally implement a prevention method against almost all vulnerabilities there could be in zlib: http://hg.dovecot.org/dovecot-1.2/rev/b359aac78f92 I had been planning this since the beginning, but since few people used zlib plugin I guess I always just treated it as second class citizen and thought other things were more important. And sure, that patch doesn't help if users have some other way of writing files to maildir, but in typical setups I would now consider using zlib plugin safe. so if I can vote, I'd say no to zlib integration. this applies to dovecot too. unfortunately, it seems that Timo is too open, which makes the with security in mind of dovecot debatable at least. is it time to move back to courier? I try to keep the defaults secure, but I also understand that others just want the best performance and fancy features.
Re: Sending SSL/TLS state to Dovecot auth
On Thu, 2009-04-16 at 20:53 -0400, Wietse Venema wrote: Postfix 2.6 will pass the TLS is active flag. I have changed the API so that we no longer need to make code changes in every SASL plugin when another attribute is added. It works with smtps but doesn't work with STARTTLS, because tls_context isn't set yet at smtpd_sasl_activate() stage. My original patch also had this problem.. signature.asc Description: This is a digitally signed message part
Re: Strange problem with postfix and dovecot sasl auth
On Mon, 2009-04-27 at 00:08 -0400, Victor Duchovni wrote:
On Mon, Apr 27, 2009 at 12:04:50AM -0400, Timo Sirainen wrote:
Oh. That's actually it. Dovecot is listening on private/auth, but Postfix
is connecting to private/dovecot. But what is listening on private/dovecot
then? You've added some kind of a dovecot service to master.cf?
Almost certainly a pipe(8) transport.
Maybe it could give a better error message in that case. Something like:
--- xsasl_dovecot_server.c.old 2009-04-26 21:43:05.0 -0400
+++ xsasl_dovecot_server.c 2009-04-26 21:42:57.0 -0400
@@ -253,7 +253,7 @@
VSTREAM *sasl_stream;
char *line, *cmd, *mech_name;
unsigned int major_version, minor_version;
-int fd, success;
+int fd, success, version_received;
int sec_props;
if (msg_verbose)
@@ -279,7 +279,7 @@
msg_warn(SASL: Couldn't send handshake: %m);
return (-1);
}
-success = 0;
+success = 0; version_received = 0;
line_str = vstring_alloc(256);
while (vstring_get_nonl(line_str, sasl_stream) != VSTREAM_EOF) {
line = vstring_str(line_str);
@@ -291,6 +291,7 @@
line = split_at(line, '\t');
if (strcmp(cmd, VERSION) == 0) {
+version_received = 1;
if (sscanf(line, %u\t%u, major_version, minor_version) != 2) {
msg_warn(SASL: Protocol version error);
break;
@@ -327,6 +328,8 @@
if (!success) {
/* handshake failed */
+if (!version_received)
+msg_warn(SASL: Protocol version not received. Connected to wrong
socket?);
(void) vstream_fclose(sasl_stream);
return (-1);
}
signature.asc
Description: This is a digitally signed message part
Re: Strange problem with postfix and dovecot sasl auth
On Apr 24, 2009, at 11:54 AM, Juha Pahkala wrote: Apr 24 15:42:50 server postfix/smtpd[8126]: fatal: no SASL authentication mechanisms .. auth default: mechanisms: plain login So Dovecot is advertising PLAIN and LOGIN mechanisms to Postfix. client: path: /var/spool/postfix/private/auth mode: 438 user: postfix group: postfix Looks correct too. I can see the private/auth socket created when dovecot starts, with postfix:postfix permissions. Also, netstat shows it: bash:# netstat -ln | grep dovecot unix 2 [ ACC ] STREAM LISTENING 111791 private/ dovecot unix 2 [ ACC ] STREAM LISTENING 120787 /var/run/ dovecot//dict-server unix 2 [ ACC ] STREAM LISTENING 120789 /var/run/ dovecot//login/default unix 2 [ ACC ] STREAM LISTENING 120800 /var/run/ dovecot/auth-master unix 2 [ ACC ] STREAM LISTENING 120803 /var/run/ dovecot//auth-worker.29982 I don't see it there. What is that private/dovecot anyway? Maybe netstat -lnp | grep dovecot would have shown the socket though. What Postfix version do you use?
Re: Strange problem with postfix and dovecot sasl auth
On Apr 26, 2009, at 11:58 PM, Timo Sirainen wrote: smtpd_sasl_path = private/dovecot .. I can see the private/auth socket created when dovecot starts, with postfix:postfix permissions. Also, netstat shows it: bash:# netstat -ln | grep dovecot unix 2 [ ACC ] STREAM LISTENING 111791 private/ dovecot I don't see it there. What is that private/dovecot anyway? Maybe netstat -lnp | grep dovecot would have shown the socket though. Oh. That's actually it. Dovecot is listening on private/auth, but Postfix is connecting to private/dovecot. But what is listening on private/dovecot then? You've added some kind of a dovecot service to master.cf?
Sending SSL/TLS state to Dovecot auth
In some setups it's useful for authentication handling to know if the
connection is SSL/TLS secured. The patch below should tell this to
Dovecot. It compiles, but other than that I haven't yet tested it.
It anyway looks like sending the SSL/TLS state requires an additional
parameter to xsasl_server_create(). Wietse, how do you think the API
should be changed to support this functionality? I guess the choices
are:
- int tls parameter as in the patch
- a more generic int flags bitmask
- secprops-like string
- replace all the existing parameters with a pointer to struct
xsasl_parameters so more stuff can easily be added to it later.
I guess I'd prefer the last one, especially because other people also
want to tell the local/remote IP addresses to SASL.
diff -ru postfix-2.5.6/src/smtpd/smtpd_sasl_glue.c
postfix-2.5.6-dovecot/src/smtpd/smtpd_sasl_glue.c
--- postfix-2.5.6/src/smtpd/smtpd_sasl_glue.c 2007-10-05 18:56:34.0
-0400
+++ postfix-2.5.6-dovecot/src/smtpd/smtpd_sasl_glue.c 2009-02-23
13:59:28.0 -0500
@@ -151,6 +151,7 @@
const char *sasl_opts_val)
{
const char *mechanism_list;
+int tls;
/*
* Initialize SASL-specific state variables. Use long-lived storage for
@@ -169,11 +170,16 @@
*/
#define SMTPD_SASL_SERVICE smtp
+#ifdef USE_TLS
+tls = state-tls_context != 0;
+#else
+tls = 0;
+#endif
if ((state-sasl_server =
xsasl_server_create(smtpd_sasl_impl, state-client,
SMTPD_SASL_SERVICE, *var_smtpd_sasl_realm ?
var_smtpd_sasl_realm : (char *) 0,
-sasl_opts_val)) == 0)
+sasl_opts_val, tls)) == 0)
msg_fatal(SASL per-connection initialization failed);
/*
diff -ru postfix-2.5.6/src/xsasl/xsasl_cyrus_server.c
postfix-2.5.6-dovecot/src/xsasl/xsasl_cyrus_server.c
--- postfix-2.5.6/src/xsasl/xsasl_cyrus_server.c2007-05-25
12:42:17.0 -0400
+++ postfix-2.5.6-dovecot/src/xsasl/xsasl_cyrus_server.c2009-02-23
14:03:21.0 -0500
@@ -157,7 +157,8 @@
VSTREAM *,
const char *,
const char *,
- const char *);
+ const char *,
+ int);
static void xsasl_cyrus_server_free(XSASL_SERVER *);
static int xsasl_cyrus_server_first(XSASL_SERVER *, const char *,
const char *, VSTRING *);
@@ -262,7 +263,8 @@
VSTREAM *stream,
const char *service,
const char *realm,
- const char *sec_props)
+ const char *sec_props,
+ int unused_tls)
{
const char *myname = xsasl_cyrus_server_create;
char *server_address;
diff -ru postfix-2.5.6/src/xsasl/xsasl_dovecot_server.c
postfix-2.5.6-dovecot/src/xsasl/xsasl_dovecot_server.c
--- postfix-2.5.6/src/xsasl/xsasl_dovecot_server.c 2008-03-16
19:09:04.0 -0400
+++ postfix-2.5.6-dovecot/src/xsasl/xsasl_dovecot_server.c 2009-02-23
14:02:49.0 -0500
@@ -160,6 +160,7 @@
char *username; /* authenticated user */
VSTRING *sasl_line;
unsigned int sec_props;/* Postfix mechanism filter */
+int tls;/* TLS enabled in this session */
char *mechanism_list;/* filtered mechanism list */
ARGV *mechanism_argv;/* ditto */
} XSASL_DOVECOT_SERVER;
@@ -172,7 +173,8 @@
VSTREAM *,
const char *,
const char *,
-const char *);
+const char *,
+int);
static void xsasl_dovecot_server_free(XSASL_SERVER *);
static int xsasl_dovecot_server_first(XSASL_SERVER *, const char *,
const char *, VSTRING *);
@@ -382,7 +384,8 @@
VSTREAM *unused_stream,
const char *service,
const char *realm,
- const char *sec_props)
+
Re: Sending SSL/TLS state to Dovecot auth
On Mon, 2009-02-23 at 14:32 -0500, Victor Duchovni wrote: On Mon, Feb 23, 2009 at 02:18:01PM -0500, Timo Sirainen wrote: In some setups it's useful for authentication handling to know if the connection is SSL/TLS secured. The patch below should tell this to Dovecot. It compiles, but other than that I haven't yet tested it. How is this useful? It seems to me that a SASL implementation should validate the credentials and leave policy questions to the MTA. The MTA can decide whether SASL without TLS is sufficient or not. It's basically the same thing as disable plaintext authentication, except on a per-user (or per-domain, or per-source-IP-range) basis rather than globally. There are probably some other use cases that I've heard before but can't remember right now. Also mere use of TLS says nothing about the security of the channel in the absense of client certification verification, There is a valid-client-cert parameter that can be used to tell dovecot-auth about that. I don't know if Postfix supports checking client certs - if it does then sure that parameter could be sent as well. the server cannot exclude MITM attackers even when a TLS session is used. The same problem exists with the global disable plaintext authentication flag. signature.asc Description: This is a digitally signed message part
Re: Sending SSL/TLS state to Dovecot auth
On Mon, 2009-02-23 at 16:49 -0500, Wietse Venema wrote: It's basically the same thing as disable plaintext authentication, except on a per-user (or per-domain, or per-source-IP-range) basis rather than globally. There are probably some other use cases that I've heard before but can't remember right now. The MTA gets the Dovecot mechanism list first, including PLAIN or LOGIN. Then the MTA sends the user's login name and password and the TLS session state, and then Dovecot says no you can't do that. What's the point? The same server may handle multiple different domains where some require that SSL/TLS is enabled for authentication to succeed, while for other domains it must be only optional. The server doesn't know if it requires SSL/TLS until it knows the SASL username. signature.asc Description: This is a digitally signed message part
Re: Sending SSL/TLS state to Dovecot auth
Mon, 2009-02-23 at 17:11 -0500, Wietse Venema wrote: Timo Sirainen: On Mon, 2009-02-23 at 16:49 -0500, Wietse Venema wrote: It's basically the same thing as disable plaintext authentication, except on a per-user (or per-domain, or per-source-IP-range) basis rather than globally. There are probably some other use cases that I've heard before but can't remember right now. The MTA gets the Dovecot mechanism list first, including PLAIN or LOGIN. Then the MTA sends the user's login name and password and the TLS session state, and then Dovecot says no you can't do that. What's the point? The same server may handle multiple different domains where some require that SSL/TLS is enabled for authentication to succeed, while for other domains it must be only optional. The server doesn't know if it requires SSL/TLS until it knows the SASL username. The client has already sent the plaintext. What problem are you trying to solve by having Dovecot say no when it is too late? It's too late for a few times (until user fixes the client configuration), but not forever (because it won't work until the configuration is fixed). Also with a laptop the initial setup is often done in a relatively safe location such as home or office, while the connections afterwards could be done in all kinds of insecure places. signature.asc Description: This is a digitally signed message part
