Mailing List Archive

Renaud Allard wrote:

> Hi,
>
> I was wondering if anyone has got experience with running exim with
> dovecot authentication.
> I tried the patch found at:
> http://www.exim.org/eximwiki/AuthenticatedSmtpUsingDovecot
> It applies without any problem with current (4.62) exim source code, but
> when trying to send a mail with authentication, I just get the following
> errors:
>
> in exim log:
> cramMD5 authenticator failed for mail.eriador.org ([172.20.0.1])
> [85.201.63.39]: 435 Unable to authenticate at present: authentication
> socket read error or premature eof
>
> in dovecot log:
> dovecot: auth(default): client in: AUTH 38 CRAM-MD5
> rip=85.201.63.39 lip=209.216.230.30 resp=
> dovecot: auth(default): BUG: Authentication client 32610 didn't specify
> service in request
>
> my dovecot version is: 1.0.rc2. I guess this patch has been made against
> an old dovecot. So if someone has got a newer patch or any idea, it will
> be welcome.
>
> PAM authentication is totally out of question as I am working with OpenBSD.
>
>

You have *me* thoroughly confused.

- The patch you reference is to implement support for a Windows
protocol available for Dovecot (but not needed) into Exim so you
can work with ..... OpenBSD?

Why do so, when even the broken-in-many-ways Windows MUA and
nearly all common non-MS MUA already support the common and
secure SSL/TLS auth available in Exim, all *BSD's, other Unix,
and Linux?

Unless you want to add MS security holes for the sake of
familiarity?

We use SSL/TLS with Exim 4.X, Dovecot .9x and 1.x on FreeBSD 4.X
and 6.X. Dovecot and Exim can use the same singel cert, separate
certs per daemon, and/or separate certs per-domain, port, or IP.

Puzzled,

Bill


--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

On Sun, 09 Jul 2006 21:52:28 +0800
W B Hacker <wbh@conducive.org> wrote:

> Renaud Allard wrote:
>
> > Hi,
> >
> > I was wondering if anyone has got experience with running exim with
> > dovecot authentication.
> > I tried the patch found at:
> > http://www.exim.org/eximwiki/AuthenticatedSmtpUsingDovecot
> > It applies without any problem with current (4.62) exim source code, but
> > when trying to send a mail with authentication, I just get the following
> > errors:
> >
> > in exim log:
> > cramMD5 authenticator failed for mail.eriador.org ([172.20.0.1])
> > [85.201.63.39]: 435 Unable to authenticate at present: authentication
> > socket read error or premature eof
> >
> > in dovecot log:
> > dovecot: auth(default): client in: AUTH 38 CRAM-MD5
> > rip=85.201.63.39 lip=209.216.230.30 resp=
> > dovecot: auth(default): BUG: Authentication client 32610 didn't specify
> > service in request
> >
> > my dovecot version is: 1.0.rc2. I guess this patch has been made against
> > an old dovecot. So if someone has got a newer patch or any idea, it will
> > be welcome.
> >
> > PAM authentication is totally out of question as I am working with OpenBSD.
> >
> >
>
> You have *me* thoroughly confused.
>
> - The patch you reference is to implement support for a Windows
> protocol available for Dovecot (but not needed) into Exim so you
> can work with ..... OpenBSD?
>
> Why do so, when even the broken-in-many-ways Windows MUA and
> nearly all common non-MS MUA already support the common and
> secure SSL/TLS auth available in Exim, all *BSD's, other Unix,
> and Linux?
>
> Unless you want to add MS security holes for the sake of
> familiarity?
>
> We use SSL/TLS with Exim 4.X, Dovecot .9x and 1.x on FreeBSD 4.X
> and 6.X. Dovecot and Exim can use the same singel cert, separate
> certs per daemon, and/or separate certs per-domain, port, or IP.
>
> Puzzled,

Ahmm, yes, indeed the example is relevant for NTLM, but should work with any other implementation. Most notably DIGEST-MD5 and GSSAPI. What I would in fact want is a common password database both for exim and dovecot where passwords are not stored in plaintext.
My server is OpenBSD. Clients are windows, linux, macosX, FreeBSD, OpenBSD (yes, all of these).
NTLM is not that a bad idea (SSL encypted) to support as it wouldn't cause problems with people checking "use secure password authentication" in outlook.
In fact, I must admit I would prefer a patch that would let dovecot authenticate against exim (which in turn supports cyrus-sasl libray even for PLAIN, LOGIN,...).

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

Renaud Allard wrote:

*trim*

> In fact, I must admit I would prefer a patch that would let
> dovecot authenticate against exim (which in turn supports
> cyrus-sasl libray even for PLAIN, LOGIN,...).
>


You don't need any patches for that, only minor compile-time
flags and appropriate configuration file settings.

Both Exim and Dovecot will use the auth methods they are told to
use and will seek the UID:GID and PWD from whatever source(es)
you point them to, plain, crypted, or both.

As an SSL 'tunnel' also protects the UID and message content as
well as the <plain> password, we consider it the best and
simplest approach [1].

Bill

[1] With older MUA that lacked SSL/TLS, we used 'stunnel'.





--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

Renaud Allard wrote:

*SNIP*

> In fact, I must admit I would prefer a patch that would let
> dovecot authenticate against exim (which in turn supports
> cyrus-sasl libray even for PLAIN, LOGIN,...).
>

Have care also as to what (system) users Exim and Dovecot run as.

One can cause them to utilize the UID:GID of the end-user for
delivery/retrieval (common).

We prefer running each under its own UID, and as members of a
common group. Virtual users thereby need no system accounts at
all, have no rights to mail storage except as authenticated
clients of Dovecot or Exim, and knowledge of a user's UID cannot
be escalated to non-mail or other-folks-mail on-box access.
Less common, AFAIK.

HTH,

Bill

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

Well, in fine, I'd like all user's passwords to be stored encrypted into a kerberos server.
Exim does not support (without cyrus-sasl) DIGEST-MD5 and GSSAPI, and it doesn't support bsdauth as a password database. However, with cyrus-sasl, it supports everything I need.
Dovecot doesn't support checking anything against cyrus-sasl, but knows about GSSAPI with its own sasl library.
I don't want to use cyrus-imapd.
What I'd like is to focalize on a centralised authenticator system, and then work on it as needed to make the central authenticator to use the kerberos server. So a patch to make dovecot use exim as an authentication system would be great as exim supports everything I want when linked against cyrus-sasl.

On Mon, 10 Jul 2006 01:07:19 +0800
W B Hacker <wbh@conducive.org> wrote:

> Renaud Allard wrote:
>
> *trim*
>
> > In fact, I must admit I would prefer a patch that would let
> > dovecot authenticate against exim (which in turn supports
> > cyrus-sasl libray even for PLAIN, LOGIN,...).
> >
>
>
> You don't need any patches for that, only minor compile-time
> flags and appropriate configuration file settings.
>
> Both Exim and Dovecot will use the auth methods they are told to
> use and will seek the UID:GID and PWD from whatever source(es)
> you point them to, plain, crypted, or both.
>
> As an SSL 'tunnel' also protects the UID and message content as
> well as the <plain> password, we consider it the best and
> simplest approach [1].
>
> Bill
>
> [1] With older MUA that lacked SSL/TLS, we used 'stunnel'.
>
>
>
>
>
> --
> ## List details at http://www.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
>


--

.O.
..O
OOO

PGP key: http://www.llorien.org/gnupg/key.pub

Insanity: doing the same thing over and over again and expecting different results.
- Albert Einstein

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

Renaud Allard wrote:

> Well, in fine, I'd like all user's passwords to be stored
> encrypted into a kerberos server.

IF '...I'd like....' means you have an operational need for
such things, then smtp itself is the wrong tool for the job.

Google 'Defense Messaging Service'. And trust than much of the
content is encrypted independently of the transmission network.

> Exim does not support (without cyrus-sasl) DIGEST-MD5 and
> GSSAPI, and it doesn't support bsdauth as a password
> database. However, with cyrus-sasl, it supports everything I
> need.
> Dovecot doesn't support checking anything against cyrus-sasl,
> but knows about GSSAPI with its own sasl library.

IMAP/POP and smtp only interact in the mailstore. They may exist
on the same server, but are not required to do so, as long as
both have access to the mailstore. Likewise their auth mechanisms.

Nothing prevents you using the same DB for multiple types of
auth. All you need is fields for each in a given record, and
appropriate key fields to find that record. These can be in a
single record, in a common DB, multiple records in a common DB,
or records in a separate.

Nothing prevents you configuring a full-featured MUA to provide
different information for smtp login than for POP/IMAP login.

*Many* things point you toward use of the methods common to
typically available MUA feature sets that folks know how to
configure.

How many users will *not* store their password in the MUA?

Even an 'Iowa Class' OpenBSD box can be no stronger than the
Win-zombie/trojan/worm magnet at the user's end.

> I don't
> want to use cyrus-imapd. What I'd like is to focalize on a
> centralised authenticator system, and then work on it as
> needed to make the central authenticator to use the kerberos
> server. So a patch to make dovecot use exim as an
> authentication system would be great as exim supports
> everything I want when linked against cyrus-sasl.
>

My Exim and Dovecot each access different fields in the same
record of a PostgreSQL DB.

The contents of such a field can match anything I can get an MUA
to hand-over. Concatenated, multi-part UIDs AND passwords for
employer/employee control, for example. And a lot more than NO
MUA can supply.

No point in reinventing the IMAP & smtp login process unless you
also plan to do a custom MUA to match.

Mixing arcane *N*X and WinWoes security models for the sake of
single-sign-on, single (point-of-failure/vulnerability) DB won't
buy you anything you will want to keep for long.

If you cannot securely store a plain-text password, you have far
larger problems than mail service security.

Bill


> On Mon, 10 Jul 2006 01:07:19 +0800 W B Hacker
> <wbh@conducive.org> wrote:
>
>
>> Renaud Allard wrote:
>>
>> *trim*
>>
>>
>>> In fact, I must admit I would prefer a patch that would
>>> let dovecot authenticate against exim (which in turn
>>> supports cyrus-sasl libray even for PLAIN, LOGIN,...).
>>>
>>
>>
>> You don't need any patches for that, only minor
>> compile-time flags and appropriate configuration file
>> settings.
>>
>> Both Exim and Dovecot will use the auth methods they are
>> told to use and will seek the UID:GID and PWD from whatever
>> source(es) you point them to, plain, crypted, or both.
>>
>> As an SSL 'tunnel' also protects the UID and message
>> content as well as the <plain> password, we consider it the
>> best and simplest approach [1].
>>
>> Bill
>>
>> [1] With older MUA that lacked SSL/TLS, we used 'stunnel'.
>>
>>
>>
>>
>>
>> -- ## List details at
>> http://www.exim.org/mailman/listinfo/exim-users ## Exim
>> details at http://www.exim.org/ ## Please use the Wiki with
>> this list - http://www.exim.org/eximwiki/
>>
>
>
>


--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

All passwords are already stored in a kerberos server _AND_ a plaintext
file (could be SQL, but this wouldn't change anything as this would be a
plaintext store anyway). However, I still need 2 password's DB to
provide all authentication possibilities. My goal is to have only one
encrypted DB to hold all of the authentication data. And this DB has to
be a kerberos server in order to provide GSSAPI auth.
The passwords should be the same for reading mail and for sending mails
as most (all?) users won't use a different password for sending and for
receiving, and I certainly don't configure 2 different realms for
sending and receiving as it would be the same as using 2 DB.


W B Hacker wrote:
> Renaud Allard wrote:
>
>> Well, in fine, I'd like all user's passwords to be stored
>> encrypted into a kerberos server.
>
> IF '...I'd like....' means you have an operational need for
> such things, then smtp itself is the wrong tool for the job.
>
> Google 'Defense Messaging Service'. And trust than much of the
> content is encrypted independently of the transmission network.
>
>> Exim does not support (without cyrus-sasl) DIGEST-MD5 and
>> GSSAPI, and it doesn't support bsdauth as a password
> > database. However, with cyrus-sasl, it supports everything I
> > need.
>> Dovecot doesn't support checking anything against cyrus-sasl,
>> but knows about GSSAPI with its own sasl library.
>
> IMAP/POP and smtp only interact in the mailstore. They may exist
> on the same server, but are not required to do so, as long as
> both have access to the mailstore. Likewise their auth mechanisms.
>
> Nothing prevents you using the same DB for multiple types of
> auth. All you need is fields for each in a given record, and
> appropriate key fields to find that record. These can be in a
> single record, in a common DB, multiple records in a common DB,
> or records in a separate.
>
> Nothing prevents you configuring a full-featured MUA to provide
> different information for smtp login than for POP/IMAP login.
>
--

.O.
..O
OOO

PGP key: http://www.llorien.org/gnupg/key.pub

Renaud Allard wrote:

> All passwords are already stored in a kerberos server _AND_ a plaintext
> file (could be SQL, but this wouldn't change anything as this would be a
> plaintext store anyway). However, I still need 2 password's DB to
> provide all authentication possibilities. My goal is to have only one
> encrypted DB to hold all of the authentication data. And this DB has to
> be a kerberos server in order to provide GSSAPI auth.
> The passwords should be the same for reading mail and for sending mails
> as most (all?) users won't use a different password for sending and for
> receiving, and I certainly don't configure 2 different realms for
> sending and receiving as it would be the same as using 2 DB.
>

Given that you believe those goals are paramount, all I can do
is wish you good luck and hope that you have the time and
mindset to enjoy the long process.

Bill


--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

On Sun, 9 Jul 2006, Renaud Allard wrote:

> All passwords are already stored in a kerberos server _AND_ a plaintext
> file (could be SQL, but this wouldn't change anything as this would be a
> plaintext store anyway). However, I still need 2 password's DB to
> provide all authentication possibilities. My goal is to have only one
> encrypted DB to hold all of the authentication data. And this DB has to
> be a kerberos server in order to provide GSSAPI auth.

If you want Kerberos you need cyrus_sasl.

Tony.
--
<fanf@exim.org> <dot@dotat.at> http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

Tony Finch wrote:
> On Sun, 9 Jul 2006, Renaud Allard wrote:
>
>> All passwords are already stored in a kerberos server _AND_ a plaintext
>> file (could be SQL, but this wouldn't change anything as this would be a
>> plaintext store anyway). However, I still need 2 password's DB to
>> provide all authentication possibilities. My goal is to have only one
>> encrypted DB to hold all of the authentication data. And this DB has to
>> be a kerberos server in order to provide GSSAPI auth.
>
> If you want Kerberos you need cyrus_sasl.
>

I already compiled exim with cyrus_sasl and it works well with GSSAPI
authentication. Exim also works well with cyrus_sasl for PLAIN, CRAM,
LOGIN as they are available in cyrus. Dovecot also works well with
PLAIN, LOGIN, GSSAPI, etc but doesn't use cyrus and isn't able to do
PLAIN, LOGIN, CRAM with the kerberos authentication. So in my case, I
have 2 databases to handle the passwords, one in plaintext for dovecot
and exim for PLAIN, LOGIN, CRAM, and one on the kerberos server for
GSSAPI. What that means is both databases should be treated differently
based on the authentication scheme, which is very unpractical. Also, if
passwords for GSSAPI are the same than plaintext ones, that means there
is a plaintext file which contains all the principals passwords, which
is IMHO a very bad idea.
So, for the moment, I think I have 2 solutions:
1: switch to cyrus-imapd (which doesn't seem a good idea to me)
2: write a patch for dovecot which uses cyrus-sasl to mimic exim's behaviour

Conclusion: I don't think this is an exim related problem anymore :)

Renaud Allard wrote:
> Tony Finch wrote:
>
>>On Sun, 9 Jul 2006, Renaud Allard wrote:
>>
>>
>>>All passwords are already stored in a kerberos server _AND_ a plaintext
>>>file (could be SQL, but this wouldn't change anything as this would be a
>>>plaintext store anyway). However, I still need 2 password's DB to
>>>provide all authentication possibilities. My goal is to have only one
>>>encrypted DB to hold all of the authentication data. And this DB has to
>>>be a kerberos server in order to provide GSSAPI auth.
>>
>>If you want Kerberos you need cyrus_sasl.
>>
>
>
> I already compiled exim with cyrus_sasl and it works well with GSSAPI
> authentication. Exim also works well with cyrus_sasl for PLAIN, CRAM,
> LOGIN as they are available in cyrus. Dovecot also works well with
> PLAIN, LOGIN, GSSAPI, etc but doesn't use cyrus and isn't able to do
> PLAIN, LOGIN, CRAM with the kerberos authentication. So in my case, I
> have 2 databases to handle the passwords, one in plaintext for dovecot
> and exim for PLAIN, LOGIN, CRAM, and one on the kerberos server for
> GSSAPI. What that means is both databases should be treated differently
> based on the authentication scheme, which is very unpractical.

Not much of a 'database' if you need a separate DB for each field of each record.

> Also, if
> passwords for GSSAPI are the same than plaintext ones, that means there
> is a plaintext file which contains all the principals passwords, which
> is IMHO a very bad idea.
> So, for the moment, I think I have 2 solutions:
> 1: switch to cyrus-imapd (which doesn't seem a good idea to me)
> 2: write a patch for dovecot which uses cyrus-sasl to mimic exim's behaviour
>
3: Learn what a real database can do for you.

4: Use the much smaller set of methods real-world MUA's actually support.

> Conclusion: I don't think this is an exim related problem anymore :)
>
>

Not to put too fine a point on it, but it never was.

Bill Hacker

--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

On Tue, Nov 16, 2021 at 11:51 AM Marc Bakos via Exim-users <
exim-users@exim.org> wrote:

> Hello. I'm trying to use the dovecot driver in exim but getting a little
> stuck.
>
> To be exact, I'm getting an error when trying to authenticate from my IMAP
> client (Thunderbird).
>
> The error in the log I get is: "Taint mismatch, string_vformat:
> auth_dovecot_server 282".
>
> I think this line in my exim config is the one in question: "server_set_id
> = $auth1"
>
> Could you confirm what other tests I could do to ensure the string data for
> $auth1 is correct? The error in the log seems like this is an error with
> data being passed in? I may be wrong, so any advice is incredibly helpful.
>

You may need to show what you have in your authenticators because according
to the spec,
that error is not supposed to occur.

37. The dovecot authenticator (exim.org)
<https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_dovecot_authenticator.html>


--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' :-)
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 11/11/2021 18:14, Marc Bakos via Exim-users wrote:
> The error in the log I get is: "Taint mismatch, string_vformat:
> auth_dovecot_server 282".

As Odihambo says, that's a shouldn't-happen error - indicating
an internal Exim bug and not something you've done wrong in your
config.

What version of Exim is this? I can tell it's not current;
282 is a line number and that source line has no code :)
It is entirely possible that this bug is already fixed.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/