[SOLVED] Postfix with authentication on the Ubuntu Server fails
UbuntuThis forum is for the discussion of Ubuntu Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
When I use Evolutions or Outlook to try to send email I get the following in the log:
/var/log/mail.log:
Code:
Jul 12 03:15:32 ubunserver postfix/smtpd[9887]: connect from host-216-153-132-55.buf.choiceone.net[216.153.132.55]
Jul 12 03:15:32 ubunserver postfix/smtpd[9887]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory
Jul 12 03:15:32 ubunserver postfix/smtpd[9887]: warning: SASL authentication failure: no secret in database
Jul 12 03:15:32 ubunserver postfix/smtpd[9887]: warning: host-216-153-132-55.buf.choiceone.net[216.153.132.55]: SASL NTLM authentication failed: authentication failure
Jul 12 03:15:32 ubunserver postfix/smtpd[9887]: warning: SASL authentication failure: realm changed: authentication aborted
Jul 12 03:15:32 ubunserver postfix/smtpd[9887]: warning: host-216-153-132-55.buf.choiceone.net[216.153.132.55]: SASL DIGEST-MD5 authentication failed: authentication failure
Jul 12 03:15:32 ubunserver postfix/smtpd[9887]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory
Jul 12 03:15:32 ubunserver postfix/smtpd[9887]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory
Jul 12 03:15:32 ubunserver postfix/smtpd[9887]: warning: host-216-153-132-55.buf.choiceone.net[216.153.132.55]: SASL LOGIN authentication failed: authentication failure
Jul 12 03:15:32 ubunserver postfix/smtpd[9887]: lost connection after AUTH from host-216-153-132-55.buf.choiceone.net[216.153.132.55]
Jul 12 03:15:32 ubunserver postfix/smtpd[9887]: disconnect from host-216-153-132-55.buf.choiceone.net[216.153.132.55]
The saslauthd test passes with:
Code:
ljames@ubunserver:/var/log$ sudo testsaslauthd -u ljames -p [passwordhere]
0: OK "Success."
/etc/postfix/main.cf:
Code:
ljames@ubunserver:/etc/postfix$ cat main.cf
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = no
# TLS parameters
smtpd_tls_cert_file = /etc/ssl/certs/smtpd.crt
smtpd_tls_key_file = /etc/ssl/private/smtpd.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
myhostname = ubunserver.apollo3.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = ubunserver.apollo3.com, localhost.apollo3.com, , localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command =
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
home_mailbox = Maildir/
smtpd_sasl_local_domain =
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination
smtp_tls_security_level = may
smtpd_tls_security_level = may
smtpd_tls_auth_only = no
smtp_tls_note_starttls_offer = no
smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
#lines added
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated
I have spent a long time trying to figure out what to do next. My whole OS and all the applications installation is very clean. Everything is from the official repositories.
Thanks in advance for anyone who has any input or suggestions. I'll gladly run any test or provide any other information needed.
so you have a log file absolutely littered with "warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory" but you've not even mentioned that... you probably want that file, no?
so you have a log file absolutely littered with "warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory" but you've not even mentioned that... you probably want that file, no?
Because I followed so closely all the steps in the Ubuntu documents and have an all native Ubuntu install, I was sure that someone else using Ubuntu would have came to this same point and knew something obvious that was left out.
I spent nearly a week wrestling with it before posting my message, and yea, I should have made reference to the fact that there is an /etc/sasldb2 file.
Thanks for pointing out what I left out. Please let me know if I'm leaving something else out.
By the way I changed the mode (of the sasldb2 file) to "chmod go+wr" to see if that made a difference. When it didn't I changed the mode back to the way it was at the default installation (the way it is in the output above).
I've been giving support for many years. I often find situations where people spend months trying to resolve issues that aren't issues to me. But again, I've spent a lot of time on various issues that aren't issues to other experienced computer users. I spent the time because I know once I learn how to resolve this issue it'll turn out to be something very simple. But so far I can't figure it out.
I appreciate your hints. I'm still stuck. Hopefully once I get it figured out others someone will take a moment and update the documentation.
I used to not have these type of problems in the past. Up until last year I only used tarballs, compiled my kernels and compiled everything that I installed on my computers. So all the locations where where I specified in my compilation. However, a little more than a year ago I tested a full installation and found some convenience in using the prebuilt (at that time rpm's but now deb files), and at this time the distro repo.
Now I'm trying to participate in the community by using the repo much to the design and testing of the developers and giving feedback. So, maybe there is some chroot component left out of the documentation. I'm looking for how I can effect this, and anything else.
Thanks again. If you know of something specific that I can actually test to facilitate in this capacity, please nudge!
I don't understand your logic here in the slightest. You are refusing to help yourself in any way and insisting on only using specific "community" support channels?? You have a problem which may or may not be related to a chroot jail config. So now you're just going to wait and see if someone who already knows this issue first hand when there are plenty of leads you can follow to work it out and then actually be able to provide back MORE to the community??
I don't understand your logic here in the slightest. You are refusing to help yourself in any way and insisting on only using specific "community" support channels?? You have a problem which may or may not be related to a chroot jail config. So now you're just going to wait and see if someone who already knows this issue first hand when there are plenty of leads you can follow to work it out and then actually be able to provide back MORE to the community??
No. I haven't refused to help myself. I've already mentioned to you that I spend a week researching before posting my message. I'm also sure that since I'm using the defaults that are provided by the developers there is something simple that may not be clear that is in the docs and someone might part.
I understand that you might not see the logic, but there is logic.
I'm still helping myself. I'm not waiting. I didn't post a message and stop performing research and various test. In fact I know that if I moved away from the postfix as provided by the distro and started anew with the tarball from the postfix site I could get it up and running. But I'm participating in a particular logic, which I' understand that you're immediately missing, of supporting the effort of the community by sharing the problem with the distribution and participating in what can become an official resolution.
I'm not dependent on the current server that I'm building, though I hope to soon replace my old server with the new one.
If I find a way to resolve the issue with the distro distribution I'll bring it back to the community.
I'm in no way waiting. I'm working and also contributing.
If you have a problem with something you work out what it is and fix it. you need to get to the end result. Then you can look at how you got there and then possibly turn that into a bug report or something which helps the community. You said you have spent weeks "researching" what I may have found in *literally* under a minute. No community is ever helped by people ignoring good advice, wherever it is from. Sharing a problem is a hell of a lot less useful than sharing a solution.
If you have a problem with something you work out what it is and fix it. you need to get to the end result. Then you can look at how you got there and then possibly turn that into a bug report or something which helps the community. You said you have spent weeks "researching" what I may have found in *literally* under a minute. No community is ever helped by people ignoring good advice, wherever it is from. Sharing a problem is a hell of a lot less useful than sharing a solution.
It's very obvious to me that you haven't tested the application in this particular case. I have tested it and it doesn't work. I'm sure if you tested it and it didn't work you'd have a clue as to why.
Of course you can get posting points by boasting at how you found a solution in minutes that doesn't work in this case and bashing the OP for not being as smart as you, and possibly doing something wrong as far as not being able to figure out something you boast that you figured out.
And yes, the community will be able to benefit from what I eventually learn.
By the way, in absent of attempting the authentication method, all other components of postfix works. To me that would someone eliminate your whim about a chroot issue.
I can do what you did to this post in every post on the forum and it might look like I know something. But boasting that I found something to test in minutes might not be as big a deal as you're making it out to be. I came up with many things in seconds when I first started the project. I'm sure lots of which you might miss and possibly take weeks to come up with, or maybe just give up and never spend a week trying to resolve the issue.
Spending time working on a problem isn't necessarily a sign of ignorance. The extremely high proficient developers of the distro spends 6 months fixing issues before publishing a release, and there are still issues.
If I use Evolutions or Microsoft Outlook without the authentication option it works flawlessly. It uses the postfix configuration files and all the other files from the /etc directory... not from a special chroot directory.
I believe your bashing of my effort is taken into concern. I appreciate if you want to contribute to the solution. But you don't have to continue following up with more bashing.
I'm working on the solution. I appreciate your comments and suggestions. I'm sure I'll get it figured out and mark the topic solved for others wanting to use Postfix authentication on Ubuntu, just as I have done with most of the topics I've started.
Thanks. But I've always had success in the past. I will in this case. The end results won't really be luck. It'll be using a mature perspective that comes with wisdom. Something that many elder people as myself develop over time.
And again, I'll bring the solution back to the community so that this configuration effort will be easier for the next person.
Oh yea, I intentionally posted this (network/server) issue in the Ubuntu forum because of the philosophy of the Ubuntu community in trying to make the operation as easy and seamless as possible. This effort has changed a number of components from it's normal defaults. I understand it's possible that another Ubuntu user haven't tested this configuration yet.
How are you doing, Chris. When I removed the system from the chroot jail I continued to have problems. The system was trying to use a saslauth2 that wasn't configured on my system, and of which I didn't want. That was some of the intentions of my description. What was the purpose of that file, even if it found it, which, of course it eventually did?
I did a few things including installing and configuring Devecot. I'll continue to study all the different components of Postfix and start to understand Devecot. I don't know if that makes a difference. The installation and configuration of it didn't resolve the issue.
I was just about to uninstall everything that I thought was pertaining to Postfix (and my effort to install it), then reinstall it or test Sendmail, then try Postfix again.
Just before uninstalling it, I reviewed the documentation page again ( https://help.ubuntu.com/community/Postfix ). It really appeared (as from the beginning) to be very simple and cut and dry. Revisiting it, it appeared that the provided steps would initiate the system, or should I say, reconfigure it as if a fresh install.
When in went to edit the “smtpd.conf file it didn't exist. I was wondering why. I looked and notice that during the first install I had mistakenly edited/created the file by the wrong name (smtp.conf). I created the file and didn't go any further than that point. I tested the server and it worked flawlessly the way I was trying to get it to work. It used the /etc/shadow file.
I gave this detailed description to help anyone else that might have problems setting up and configuring Postfix for authentication using the /etc/shadow file. The question is asked many times on the Internet and described as a nightmare to make it work. Some of that might have contributed to my having such difficulty (expecting difficulty).
I guess I left a few important componets out of my original post. I thought my reference to authentication would indicate to the people reading that I was trying to use the /etc/shadow option. I thought I had posted my /etc/default/saslauthd, which has that option set. I should have posted my /etc/smptd.conf file. Had I done that I'm sure someone would have quickly noticed that error (probably even me).
Anyway, the steps on the documentation page appear to work as published.
Thanks again, Chris for the input. Keep up the good work you're doing on the forum. I especially think you for tolerating my method of trying to get things done. In this case I didn't describe the objective and steps taken clear enough. Again, your response opened up the saslauth2 database method, which wouldn't work in my case because I don't have a saslauth2 database of users. I have a /etc/passwd system of users.
I have already replaced my outgoing server with the new one. It’s working great. I'm glad to retire the Redhat/Fedora Core 6 from this job. It still has other jobs that I'll soon be replacing by my other machines.
My next step is to configure the new mail server as a delivery machine. But that's for a new thread after I've spend some time working with it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
