Rom <rompe...@gmail.com> wrote:
> I'm running into a problem with Sendmail trying to implement SMTP-
> auth. I"m running 8.14.5 and have saslauthd running.
> I don't believe I have starttls enabled - just looking for basic auth,
> but am wondering if my configuration is not compatible with modern
> mail clients? I don't think I have any certs set up.
I wouldn't worry about what clients work and which don't, I don't think
you finished the install.
Did you stick something like this into the sendmail.mc ...
and rebuild the sendmail.cf, install it, restart sendmail?
One other thought, the way you added the libraries in the build, is there a
/usr/local/lib/sasl2/Sendmail.conf for the saslauth stuff? It's just a text
file with
Some os's also need a soft link pointing /usr/local/lib/sasl to
/usr/local/lib/sasl2.
Also just common sense, check the related syslog files when sendmail starts
to make sure it's not throwing any errors about anything at all (missing
libs, configuration errors).
Rom <rompe...@gmail.com> wrote:
> I hope I corrected any thing you cited from above where a ` or ' was
> left out? it seems to use the backtick ` to preceede paramaters and
> the apostrophe after them '
Yeah, the copy/paste I did screwed that up, you have it right.
> I also tried just what you specified:
> define(`ConfAUTH_OPTIONS',`A')
> TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
> define(`ConfAUTH_MECHANISMS',` LOGIN PLAIN')dnl
> And I still get auth error
> then tried this:
> # telnet localhost 587
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> 220 x ESMTP Sendmail 8.14.5/8.14.5; Sat, 16 Jun 2012 11:56:23 -0500
> (CDT)
> ehlo localhost
> 250-x Hello localhost [127.0.0.1], pleased to meet you
> 250-ENHANCEDSTATUSCODES
> 250-PIPELINING
> 250-8BITMIME
> 250-SIZE
> 250-DSN
> 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
> 250-DELIVERBY
> 250 HELP
Well, it's not clear to me with the "then tried this", but if you put in
define(`ConfAUTH_MECHANISMS', LOGIN PLAIN')dnl
You wouldn't get...
250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
With the telnet localhost test, only LOGIN PLAIN should show up, so either
you are editing the wrong file, the make isn't regenerating the sendmail.cf
from it or sendmail is looking at some other cf file when it starts.
It's been a while since I used freebsd but in /etc/mail doesn't the mc file
need to be copied from the default (freebsd.mc) to like hostname.mc and that
file edited/ran make on and so forth?
Rom <rompe...@gmail.com> wrote:
> this also shows up in the log when I restart:
> Jun 16 12:53:39 x sm-mta[81145]: sql_select option missing
> Jun 16 12:53:39 x sm-mta[81145]: auxpropfunc error no mechanism
> available
This might be relevant.
Where did you get saslauthd from? Built it or used ports?
Those two errors are from sasl complaining, but they might be harmless.
What it does possibly point to though, I think after some version of
cyrus-sasl, the default build left out --enable-plain --enable-login,
requiring one of the other mechs (krb4, gssapi or whatever) and you would
need to hand compile it to put back in the plain/login functions.
Older versions had those enabled by default, later versions (like 2.1.12)
did not.
So unless you can verify the compile options used for sasl, you might need
to hand compile it from source to put back in the plain/login features.
It's a shot in the dark, I still think the problem is with the sendmail.mc
file or rebuilding it.
Rom <rompe...@gmail.com> wrote:
> I also noticed under sendmail, in the logfile the username was
> user@host, which would be different than in /etc/passwd so I wonder if
> there's a format mismatch for that mech, or sasl isn't configured to
> support crap-md5. Any way I can test this?
> I'm seeing this in the log file verifying i can do smtp-auth with cram-
> md5 removed:
> Jun 17 17:35:08 x sm-mta[29858]: AUTH=server, relay=x [x],
> authid=username, mech=LOGIN, bits=0
> I'm wondering:
> * are there any other auth mechs sendmail may accept that may not
> work?
> * Can I get cram-md5 or others to work?
I had a problem years ago where sasl required its own passwords to authenticate. The version of Ubuntu that I am running now has shadow as a sasl mech, I think solving that. Try using saslpasswd2 to set your password and then log in with CRAM-MD5 only and I'll bet it works.
> On Jun 17, 11:00 pm, Knute Johnson <nos...@knutejohnson.com> wrote:
>> On 6/17/2012 4:54 PM, Rom wrote:
>>> I'm seeing this in the log file verifying i can do smtp-auth with cram-
>>> md5 removed:
>>> Jun 17 17:35:08 x sm-mta[29858]: AUTH=server, relay=x [x],
>>> authid=username, mech=LOGIN, bits=0
>>> I'm wondering:
>>> * are there any other auth mechs sendmail may accept that may not
>>> work?
>>> * Can I get cram-md5 or others to work?
>> I had a problem years ago where sasl required its own passwords to
>> authenticate. The version of Ubuntu that I am running now has shadow as
>> a sasl mech, I think solving that. Try using saslpasswd2 to set your
>> password and then log in with CRAM-MD5 only and I'll bet it works.
>> --
>> Knute Johnson
> Does this mean sasl has it's own separate password database?
It can.
And for
> anyone I want to authenticate for smtp auth I have add an extra step
> of using that program to define the password?
No. My current setup has shadow as one of the authentication mechanisms and that solves that problem.
> If so, am I right in assuming that the username will be the
> username@hostname instead of just username?
I don't think so.
I think you just want to get your sasl set up so that it can use "shadow" as a auth mechanism. I'm not sure how you do that though.
> On 6/17/2012 9:18 PM, Rom wrote:
>> On Jun 17, 11:00 pm, Knute Johnson <nos...@knutejohnson.com> wrote:
>>> On 6/17/2012 4:54 PM, Rom wrote:
>>>> I'm seeing this in the log file verifying i can do smtp-auth with cram-
>>>> md5 removed:
>>>> Jun 17 17:35:08 x sm-mta[29858]: AUTH=server, relay=x [x],
>>>> authid=username, mech=LOGIN, bits=0
>>>> I'm wondering:
>>>> * are there any other auth mechs sendmail may accept that may not
>>>> work?
>>>> * Can I get cram-md5 or others to work?
>>> I had a problem years ago where sasl required its own passwords to
>>> authenticate. The version of Ubuntu that I am running now has shadow as
>>> a sasl mech, I think solving that. Try using saslpasswd2 to set your
>>> password and then log in with CRAM-MD5 only and I'll bet it works.
>>> --
>>> Knute Johnson
>> Does this mean sasl has it's own separate password database?
> It can.
> And for
>> anyone I want to authenticate for smtp auth I have add an extra step
>> of using that program to define the password?
> No. My current setup has shadow as one of the authentication mechanisms
> and that solves that problem.
>> If so, am I right in assuming that the username will be the
>> username@hostname instead of just username?
> I don't think so.
> I think you just want to get your sasl set up so that it can use
> "shadow" as a auth mechanism. I'm not sure how you do that though.
I've been playing around with this and looking at articles on the net and I think I can't run SASL and use the -MD5 passwords because of the sendmail program and the way it authenticates. At least that is what I gather from what I've read. My system is set up to use TLS and LOGIN and PLAIN mechanisms. I know years ago on a Fedora box that I had to put the passwords into the sasldb to get them to work with the -MD5 passwords but this Ubuntu server is set up differently.
Knute Johnson <nos...@knutejohnson.com> wrote:
> I think you just want to get your sasl set up so that it can use > "shadow" as a auth mechanism. I'm not sure how you do that though.
That's what I mentioned before, to get certain options you need to compile
it by hand and not rely on ported pre-compiled binaries.
I think the configure needs to be ran with --enable-plain --enable-login as
part of the arguments to use shadow passwords. These used to be enabled by
default and maybe starting with "v2" they were disabled by default.
It's the same with UofW imapd, cleartext non-ssl logins are off by default,
you have to enable them to use them, getting a stern warning not to do it.
