Anyone have a chance to look at this?  I've updated everything in stable updates for f15 and it still happens.  The only way I can send mail is to turn off smtp auth, which restricts sending to webmail and my local subnet, which is less than ideal.

FWIW, I can confirm this is a problem.  

kernel: [ 4172.223753] sendmail[10991]: segfault at 1c ip 00557b43 sp bfa804b0 error 4 in libdb-5.1.so[475000+18a000]

Name        : libdb
Arch        : i686
Version     : 5.1.25
Release     : 2.fc15

As a test, I rebuild and re-installed (my version of) libdb 5.1.25-2.fc15 on a current FC15 system; the idea being that maybe there was a fix in one of the build libraries.  No dice, same error.

Hey Jon, I figured out what the problem is, at least on my system.  

/etc/mail/sendmail.mc contains:

define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl

This is (presumably) a Berkley DB.  My guess is that this is to allow sendmail to define it's own user auth database.  The thing is, I haven't created that database on my system.  I think the sigfault is due to the fact that sendmail was configured to use a non-existent database.  

I just commented the line as such:

dnl define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl

ran make and restarted sendmail and now smtp auth works without the segfault error.

Interesting.  I don't have that DB either, but I also already had that line dnl'd.  Reran make, restarted sendmail, still have the segfault when attempting SMTP auth.

Look for any other Berkeley DB references in sendmail.mc that don't map to databases stored in /etc/mail.  

I would check the configuration files of the following db files:

dbs:
access.db
domaintable.db
mailertable.db
virtusertable.db

i.e.:
access
domaintable
mailertable
virtusertable

for any configuration errors.  

Also, I have:  

/etc/sasl2/Sendmail.conf:

pwcheck_method:saslauthd
mech_list: login plain

/etc/pam.d/smtp:

#%PAM-1.0
auth       include      system-auth
account    include      system-auth

Those are the other relevant settings I can think of.  

The important point, using my case as an example, is that in the end it is likely related to a configuration problem, albeit a difficult one to troubleshoot.  

There probably is some sort of problem with the libdb library.  One would at least expect an error instead of a segmentation fault.

I tried moving my db files aside and regenerating, no luck.  I checked the corresponding configs, all were fine.  Then I checked my /etc/sasl2/Sendmail.conf, and I had the pwcheck_method line, but not the mech_list line.  I added it, restarted saslauthd and sendmail and it worked!  Thank you!!!!

So it looks like a config handling change in cyrus-sasl, and then, yes, some variety of libdb issue.

I have the same issue that I'm having trouble with. my configuration of cyrus-sasl and sendmail is a little different. I've tried regenerating all the /etc/sendmail/*.db files also my sendmail.cf.

sendmail.cf (Replaced [my domain name] with 'my'):

divert(0)dnl
VERSIONID(`$Id: sendmail.mc,v 8.1 2010/03/25 22:48:05 gshapiro Exp $')
OSTYPE(linux)dnl
DOMAIN(my.com)dnl
define(`confDEF_USER_ID',``8:12'')dnl
define(`confTRUSTED_USER', `cyrus')dnl
define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST',true)dnl
define(`confDONT_PROBE_INTERFACES',true)dnl
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl
define(`ALIAS_FILE', `/etc/aliases')dnl
define(`UUCP_MAILER_MAX', `200000000')dnl
define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl
define(`confAUTH_OPTIONS', `A,p,y')dnl
TRUST_AUTH_MECH(`EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confCACERT_PATH',`/etc/pki/tls/certs')
define(`confCACERT',`/etc/pki/tls/certs/ca-bundle.crt')
define(`confSERVER_CERT',`/etc/pki/tls/certs/mail.my-email-cert.pem')
define(`confSERVER_KEY',`/etc/pki/tls/private/mail.my-email-key.pem')
define(`confCLIENT_CERT',`/etc/pki/tls/certs/mail.my-email-cert.pem')dnl
define(`confCLIENT_KEY',`/etc/pki/tls/private/mail.my-email-key.pem')dnl
define(`confTLS_SRV_OPTIONS',`V')dnl
define(`confTO_IDENT', `0')dnl
define(`confLOCAL_MAILER', `cyrusv2')dnl
define(`CYRUSV2_MAILER_ARGS', `FILE /var/lib/imap/socket/lmtp')dnl
FEATURE(`no_default_msa',`dnl')dnl
FEATURE(`smrsh',`/usr/sbin/smrsh')dnl
FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
FEATURE(always_add_domain)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
FEATURE(local_procmail,`',`procmail -t -Y -a $h -d $u')dnl
FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')dnl
FEATURE(`blacklist_recipients')dnl
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
FEATURE(`accept_unresolvable_domains')dnl
LOCAL_DOMAIN(`localhost.localdomain')dnl
MAILER(local)dnl
MAILER(smtp)dnl
MAILER(cyrusv2)dnl
MAILER(procmail)dnl
LOCAL_CONFIG
CPprocmail
LOCAL_RULESETS
LOCAL_RULE_0
R$* < @ $=w > $*    	$#procmail $@ /etc/procmailrc $: $1<@$2.procmail.>$3
R$* < @ $=w. > $*   	$#procmail $@ /etc/procmailrc $: $1<@$2.procmail.>$3
R$* < @$* .procmail. > $*  	$1<@$2.>$3 	Already filtered, map to original address


/etc/sasl2/Sendmail.conf:

pwcheck_method: auxprop saslauthd
auxprop_plugin: sasldb
auto_transition: true
mech_list: LOGIN PLAIN CRAM-MD5 DIGEST-MD5


/etc/sysconfig/saslauthd:

SOCKETDIR=/var/run/saslauthd
START=yes
MECH=pam
FLAGS=

/etc/pam.d/smtp:

#%PAM-1.0
auth       include      password-auth
account    include      password-auth

I just upgrade from fc14 to fc15 and have the same problem.

kernel: [16277.660063] sendmail[12880]: segfault at 30 ip 00007f329afe4fc8 sp 00007fff5c231660 error 4 in libdb-5.1.so[7f329af07000+179000]

I probe all above and nothing.

Could you try the following test build?
http://koji.fedoraproject.org/koji/taskinfo?taskID=3215805

Looks like a vanilla 8.14.5 build? I've already tried a rebuild of 8.14.5 from Rawhide and it didn't help. Next on my to-do list will be to see if libdb-5.2 is similarly affected.

We got the same problem.
I tried the test build, and still have this issue.

Our situation:
sendmail / cyrus-imapd with virtual domains.
cyrus authenticates with sasldb2 database (/etc/sasldb2 ) which works fine.
sendmail works fine except when trying to relay with TLS and plain passwords using the same /etc/sasldb2 authentication.

This problem occurred since upgrading to FC15.
Same configuration with sendmail 8.14.4 worked fine.

After downgrading to sendmail 8.14.4-20 we still got the same problem. So maybe it's a problem in the libdb-5.1 package?

Also tried the .i686 versions, which has the sane problem for us.

Not a fix, but maybe someone else is in need of a quick way to get sendmail TLS auth working. with sasldb2.

Found a work-around. Instead of using the sasldb2 directly from sendmail, change the /usr/lib/sasl2/Sendmail.conf (or /usr/lib64.... or on some systems /etc/...)

to

pwcheck_method: saslauthd
mech_list: LOGIN PLAIN

configure /etc/sysconfig/saslauthd as follows:
MECH=rimap
DAEMONOPTS=--user saslauth
FLAGS="-O localhost -r"

This requires the cyrus-imapd to run (we use this anyway)
start the saslauthd
restart sendmail

sendmail will authenticate to the saslauthd instead of the sasldb2
saslauthd authenticates to your local imapd (cyrus) which authenticates to the /etc/sasldb2

For me this worked, not the perfect way, but useable for a temporarily solution.

I believe I have found the problem. In Fedora 15, cyrus-sasl is still linked against libdb-4.8.so, whereas sendmail is linked against libdb-5.1.so. So confusion ensues when both libraries are needed in the same process.

I have rebuilt cyrus-sasl with libdb-5.1, updated my system with the new cyrus-sasl* packages, restarted sendmail and the problem went away.

Anyone wanting to try this can find a scratch build here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3227292

Paul thanks, it is working for me.

Jan, could you rebuilt cyrus-sasl with libdb-5.1?

Created attachment 515054 [details]
Patch for db5 support

(In reply to comment #18)
> Jan, could you rebuilt cyrus-sasl with libdb-5.1?

It'll need this patch (which I took from debian), and changing the buildreq db4-devel to libdb-devel.

It'll also need updating in Rawhide, which has libdb-5.2.

cyrus-sasl-2.1.23-17.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/cyrus-sasl-2.1.23-17.fc15

(In reply to comment #21)
> cyrus-sasl-2.1.23-17.fc15 has been submitted as an update for Fedora 15.
> https://admin.fedoraproject.org/updates/cyrus-sasl-2.1.23-17.fc15

Unfortunately this build doesn't help as the db4-devel buildreq wasn't changed to libdb-devel and so it's still built against libdb-4.8.so.

Package cyrus-sasl-2.1.23-17.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing cyrus-sasl-2.1.23-17.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/cyrus-sasl-2.1.23-17.fc15
then log in and leave karma (feedback).

cyrus-sasl-2.1.23-18.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/cyrus-sasl-2.1.23-18.fc15

cyrus-sasl-2.1.23-18.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

I've tried the new package.

Have not tried the old bug because I ran up to a new problem immediately.
After updating cyrus-imapd and cyrus-sasld did not want to read my sasldb2 file anymore.
Probably because of the new linkage to a new version of libdb?

imaps[4495]: unable to open Berkeley db /etc/sasldb2: Invalid argument

This is a big issue for us, and had to rollback to the old version.
I could not find any easy solution to "convert" the sasldb2 file, and it almost impossible for us to recreate a version.

(In reply to comment #26)
I am unable to reproduce. But in case of trouble the db dump/re-create could help, e.g. something like:

# db_dump -p /etc/sasldb2 > dump  # before update
# rm /etc/sasldb2
# db_load /etc/sasldb2 < dump # after update

I thought of something like that but unfortunately libdb-utils (which contains the DB5 db_load) appears to be uninstallable as it conflicts with db4-utils and that package can't be removed as it's required by rpm itself.

I had the same issue. The way i fixed it was

i submited 
https://bugzilla.redhat.com/show_bug.cgi?id=729767

cleaned up db4:

rpm -e --nodeps db4-utils

installed libdb

yum install libdb-utils 

then installed the testing version of cyrus-imapd with the libdb.5.1 build support.

Everything works fine now with mine.

To be safe and not to mod your stable system, you can go through chroot, e.g. use mock:
# yum install mock
Add yourself to mock group
$ mock -r fedora-15-x86_64 --init
$ mock -r fedora-15-x86_64 --chroot 'rpm -e --nodeps db4-utils'
$ mock -r fedora-15-x86_64 --install libdb-utils
# db_dump -p /etc/sasldb2 > /tmp/dump
$ mock -r fedora-15-x86_64 --copyin /tmp/dump /tmp
$ mock -r fedora-15-x86_64 --chroot '/usr/bin/db_load /etc/sasldb2 < /tmp/dump'
$ mock -r fedora-15-x86_64 --copyout /etc/sasldb2 /tmp
$ mock -r fedora-15-x86_64 --clean
# mv /tmp/sasldb2 /etc/

Didn't have time to test it before.

First I tried the mock solution.

The result sasldb2 file is exactly the same size as the original, but that could be coincidence.
After updating to the latest cyrus-sasl packages, I still got the errors:

imaps[23111]: badlogin: some.host.com [1.2.3.4] PLAIN [SASL(-13): user not found: Password verification failed]

So I tried the solution from Tomothy Sink
db4-utils is used by cyrus-imapd and the yum rpm's, but tried it anyways...

Then I get like hundreds of these errors:

Sep 29 07:59:57 merel pop3[1386]: DBERROR db4: PANIC: fatal region error detected; run recovery
Sep 29 07:59:57 merel imap[1384]: DBERROR: critical database situation
Sep 29 07:59:57 merel imap[1395]: DBERROR db4: PANIC: fatal region error detected; run recovery
Sep 29 07:59:57 merel pop3[1386]: DBERROR: critical database situation
Sep 29 07:59:57 merel pop3s[1387]: DBERROR db4: PANIC: fatal region error detected; run recovery

Probably because the cyrus-imapd is still linked with the db4-utils library.

Then I noticed the summited bug from Timothy, and read that tread carefully and installed the updated cyrus-imapd from the testing repository. Bingo! It worked.

Thanks!