Sendmail 8.12.11 SMTP AUTH question
Rob MacGregor
Currently when people authenticate to Sendmail they have to provide
the domain, as shown in sasldblistusers2, eg:
t...@local.domain: userPassword
fr...@local.domain: userPassword
What I'd like is for people to only have to provide their username, as
they do for the IMAP server. Is this possible (ie have I missed the
obvious documentation)? Is there some way to provide a default
domain/realm?
My Sendmail.conf looks like:
pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: /etc/sasldb2
TIA
--
Rob MacGregor (BOFH) Oh my God! They killed init! You bastards!
The light at the end of the tunnel is an oncoming dragon.
Andrzej Adam Filip
> Time for an odd question - I'm using Sendmail 8.12.11 with SASL 2.1.17.
> Currently when people authenticate to Sendmail they have to provide the
> domain, as shown in sasldblistusers2, eg:
>
> t...@local.domain: userPassword
> fr...@local.domain: userPassword
>
> What I'd like is for people to only have to provide their username, as
> they do for the IMAP server. Is this possible (ie have I missed the
> obvious documentation)? Is there some way to provide a default
> domain/realm?
>
> My Sendmail.conf looks like:
>
> pwcheck_method: auxprop
> auxprop_plugin: sasldb
> sasldb_path: /etc/sasldb2
What about making IMAP support user@domain logins ?
It will reduce number of things user have to remember from 3 to 2:
email,login,password => email==login, password
--
Andrzej [en:Andrew] Adam Filip http://anfi.freeshell.org backup: an...@xl.wp.pl
*Random Epigram* :
A hundred men may make an encampment, but it takes a woman to make a home.
-- Chinese Proverb
Rob MacGregor
> What about making IMAP support user@domain logins ?
>
> It will reduce number of things user have to remember from 3 to 2:
> email,login,password => email==login, password
That's possible, though it would be slightly more pain because the local
domain doesn't match the email domain. Right now however the list of
users is fairly small (less than a dozen) so it wouldn't take much more
than an hour to switch all the accounts over.
Has to be said though that they don't tend to remember their email
address - the login name they can cope with because it's their first
name (hey, it's family based, the odds of a collision are small).
Jennifer Knoell
> Time for an odd question - I'm using Sendmail 8.12.11 with SASL 2.1.17.
> Currently when people authenticate to Sendmail they have to provide
> the domain, as shown in sasldblistusers2, eg:
>
> t...@local.domain: userPassword
> fr...@local.domain: userPassword
>
> What I'd like is for people to only have to provide their username, as
> they do for the IMAP server. Is this possible (ie have I missed the
> obvious documentation)? Is there some way to provide a default
> domain/realm?
>
> My Sendmail.conf looks like:
>
> pwcheck_method: auxprop
> auxprop_plugin: sasldb
> sasldb_path: /etc/sasldb2
>
> TIA
Change that to:
pwcheck_method: shadow
This way it'll use the default passwd/shadow file.
Jennifer
Alexander Dalloz
But this way you loose md5 auth mechanism.
> Jennifer
Alexander
--
Alexander Dalloz | Enger, Germany
PGP key valid: made 13.07.1999
PGP fingerprint: 2307 88FD 2D41 038E 7416 14CD E197 6E88 ED69 5653
Rob MacGregor
> Change that to:
> pwcheck_method: shadow
>
> This way it'll use the default passwd/shadow file.
It will, but there's a reason I don't use it - no accounts! It's purely
a mail server so there are no local user accounts.
Annoyingly in theory this should "just work". If you don't provide a
domain then SASL is supposed to use the hostname.
However, I've found the problem. Sendmail is appending the domain name
of the mail server to the login. I need to work out where it's doing
this and see if I can persuade it to use the hostname instead, or just
leave it blank.
Thanks all.
Claus Aßmann
> However, I've found the problem. Sendmail is appending the domain name
> of the mail server to the login. I need to work out where it's doing
> this and see if I can persuade it to use the hostname instead, or just
> leave it blank.
Are you sure it's sendmail?
Maybe it's an internal function of Cyrus-SASL...
Have you tried to set the passwords without a realm
(empty realm) for sasldb?
Anyway, if you want to hack sendmail: look for sasl_server_new()
Here's a part from the Cyrus-SASL 2 docs:
result=sasl_server_new("smtp", /* Registered name of service */
NULL, /* my fully qualified domain name;
NULL says use gethostname() */
NULL, /* The user realm used for password
lookups; NULL means default to serverFQDN
Note: This does not affect Kerberos */
NULL, NULL, /* IP Address information strings */
NULL, /* Callbacks supported only for this connection */
0, /* security flags (security layers are enabled
* using security properties, separately)
&conn);
You probably want to set the realm.
--
A: Maybe because some people are too annoyed by top-posting.
Q: Why do I not get an answer to my question(s)?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Rob MacGregor
> Are you sure it's sendmail?
>
> Maybe it's an internal function of Cyrus-SASL...
90% certain (at least until you provided the snippet below), the
official Cyrus-SASL documentation says that if you don't provide the
real it uses the local hostname as a default. Some experimentation
indicates this is probably true.
Connecting as "rob" with password "fred" to Cyrus IMAP works fine,
because by not providing the real it defaults to "mail.macgregor",
matching "r...@mail.macgregor" in the SASL password file.
Connecting as "rob" with password "fred" to Sendmail however fails,
because it's trying to look for "r...@mail.domain" instead. I confirmed
this by adding an "r...@mail.domain" to the SASL password file, and that
default is ok.
Any user created without an explicit realm is created with a realm of
the local hostname.
> Have you tried to set the passwords without a realm
> (empty realm) for sasldb?
Just tried that, and you can't. If you specify a blank realm you get
the local hostname.
> Anyway, if you want to hack sendmail: look for sasl_server_new()
One question:
# if SASL >= 20000
result = sasl_server_new("smtp", hostname, NULL, NULL, NULL,
NULL, 0, &conn);
# elif SASL > 10505
/* use empty realm: only works in SASL > 1.5.5 */
result = sasl_server_new("smtp", hostname, "", NULL, 0, &conn);
# else /* SASL >= 20000 */
/* use no realm -> realm is set to hostname by SASL lib */
result = sasl_server_new("smtp", hostname, NULL, NULL, 0,
&conn);
The comment on the last else doesn't make any sense to me. That surely
will be reached only if SASL < 10505?
> Here's a part from the Cyrus-SASL 2 docs:
>
> result=sasl_server_new("smtp", /* Registered name of service */
> NULL, /* my fully qualified domain name;
> NULL says use gethostname() */
> NULL, /* The user realm used for password
> lookups; NULL means default to serverFQDN
> Note: This does not affect Kerberos */
> NULL, NULL, /* IP Address information strings */
> NULL, /* Callbacks supported only for this connection */
> 0, /* security flags (security layers are enabled
> * using security properties, separately)
> &conn);
>
> You probably want to set the realm.
Yeah, the problem is, persuading mail clients to play with the real
isn't trivial. A quick check with Mozilla Thunderbird yesterday showed
it wasn't going to play (it complained about cross domain
authentication). Similarly Outlook (2003) fails if I provide the realm.
I'll have a trawl through the sources later and see if I can nail down
exactly what's going on.
Thanks
Tilman Schmidt
>Connecting as "rob" with password "fred" to Cyrus IMAP works fine,
>because by not providing the real it defaults to "mail.macgregor",
>matching "r...@mail.macgregor" in the SASL password file.
>
>Connecting as "rob" with password "fred" to Sendmail however fails,
>because it's trying to look for "r...@mail.domain" instead. I confirmed
>this by adding an "r...@mail.domain" to the SASL password file, and that
>default is ok.
>
>Any user created without an explicit realm is created with a realm of
>the local hostname.
>[...] the problem is, persuading mail clients to play with the real[m]
>isn't trivial.
BTDT. See <40154e33$1...@news.piro.net> for the solution I finally
settled on. If anyone has a better one (for appropriate values of
"better") I will gladly hear it.
--
Tilman Schmidt E-Mail: Tilman....@ePost.de
Bonn, Germany
- In theory, there is no difference between theory and practice.
In practice, there is.