Re: Some DNSSEC/DANE questions
Dan Mahoney wrote >> Here's an SMTP DANE validator that I use when I make changes to my server. >> https://dane.sys4.de/ >> >> I'm not sure if it is just what you're looking for, though. > > No, I am looking for a server to which I can send mail to make sure DANE is > being looked up and used on my end. > Not something that looks up MY domain and connects to it. You may send a mail to e...@sys4.de instead. Regards, Michael
Re: SMTP over IPv6
On Mon, Jan 03, 2022 at 10:39:49PM -0500, post...@ptld.com wrote: >smtp_bind_address6 = [] > > If I remove the [ ] around the IPv6 the error goes away. The manual > says [ ] is supported. Is my version is too old? Im okay with not > using [ ]. Indeed the implementation does not match the documentation, presently only the bare address is supported here. There is no ambiguity wrt. table syntax, ":port" suffixes etc., this field is just an address. > If i use these settings >inet_interfaces = all >inet_protocols = all >smtp_bind_address = >smtp_bind_address6 = >smtp_address_preference = any (* Not actually included in main.cf, > relying on 'any' as the default) The expected behaviour is that ipv4 and ipv6 addresses will be tried in roughly their relative frequency among the best preference MX hosts of the destination, unless there are enough of them that the weights are skewed by the address limits which try to ensure that at least some of each family are represented. > Then most of the time email being sent out to another server will be > delivered over IPv6. This is not what sufficiently recent Postfix versions are expected to do. > It rarely uses IPv4. However, if I supply the > IP's instead of using "all" for interfaces then it mostly sends out > over IPv4 and used IPv6 only once out of 10 emails sent. Many destination domains don't have IPv6 MX hosts. > I tried both ways, putting the IPv4 first, then tried putting IPv6 > first. And no not both config lines at the same time. The order does not matter, the only thing that matters is whether either or both are listed. -- Viktor.
Re: Mail system is down
Ken Wright: > On Mon, 2022-01-03 at 20:50 -0500, Viktor Dukhovni wrote: > > On Mon, Jan 03, 2022 at 08:02:20PM -0500, Ken Wright wrote: > > > > > $ sudo chmod g+s /usr/sbin/postdrop > > > $ ls -la /usr/sbin/postdrop > > > -r-xr-sr-x 1 postfix postdrop 22808 Sep? 7 02:58 /usr/sbin/postdrop > > > > > > Wietse, is this what's expected? > > > > > > The expected permissions are recorded in the "postfix-files" file, > > and applied by running (as root) "postfix set-permissions". > > > > If your Postfix software is packaged correctly by the OS > > distribution, this will apply the relevant permissions to all > > executables, directories and configuration files. > > > > If the distribution package is sloppy,? you may see warnings about > > missing files, ... > > Okay, I ran sudo postfix set-permissions. It ran with no trouble > whatsoever; no errors, warnings, nothing. Still getting the exact same > messages in mail.log. Then your file system is mounted with 'nosuid' option. Don't do that. Wietse
Re: SMTP over IPv6
post...@ptld.com: > If i use these settings >inet_interfaces = all >inet_protocols = all >smtp_bind_address = >smtp_bind_address6 = >smtp_address_preference = any (* Not actually included in main.cf, > relying on 'any' as the default) > > Then most of the time email being sent out to another server will > be delivered over IPv6. It rarely uses IPv4. However, if I supply May we know the domain name? The addres selection depends on how many IPv6 versus IPv4 addresses its MX hosts have. Postfix versions with 'smtp_balance_inet_protocols' support will ensure that some number of addresses from each family will be tried even if the primary MXes have more IPv6 addresses than IPv4 (or more IPv4 than IPv6). wietse
Re: Mail system is down
Am 04.01.2022 um 02:02 schrieb Ken Wright: $ sudo chmod g+s /usr/sbin/postdrop $ ls -la /usr/sbin/postdrop -r-xr-sr-x 1 postfix postdrop 22808 Sep 7 02:58 /usr/sbin/postdrop Wietse, is this what's expected? AFAICT you are lacking write permission for the user. -- Alex JOST
Re: Mail system is down
Alex JOST: > Am 04.01.2022 um 02:02 schrieb Ken Wright: > > $ sudo chmod g+s /usr/sbin/postdrop > > $ ls -la /usr/sbin/postdrop > > -r-xr-sr-x 1 postfix postdrop 22808 Sep 7 02:58 /usr/sbin/postdrop > > > > Wietse, is this what's expected? > > AFAICT you are lacking write permission for the user. This program must NOT be writable by users. Wietse
different mechanism filter for two ISPs
My postfix setup sends all emails through google. Now trying to route some of them through dreamhost. AUTH from [gmail-smtp.l.google.com]:587 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH AUTH from [smtp.dreamhost.com]:587 250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN To send through google, I have this line in main.cf smtp_sasl_mechanism_filter = xoauth2 which breaks sending through dreamhost. I get (SASL authentication failed: server smtp.dreamhost.com[64.90.62.162] offered no compatible authentication mechanisms for this type of connection security) If I remove that line it works through dreamhost, but not through google. I think this could work setting up something like: smtp_sasl_mechanism_filter = hash:/etc/postfix/smtp_mechs but not sure what the "key value" format needs to be. Redirection through google or dreamhost is handle through relayhost = [gmail-smtp.l.google.com]:587 smtp_tls_policy_maps = hash:/etc/postfix/tls_policy smtp_use_tls = yes smtp_tls_security_level = may smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = noanonymous smtp_sasl_tls_security_options = noanonymous smtp_sender_dependent_authentication = yes sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay /etc/postfix/tls_policy contains the single line: [gmail-smtp.l.google.com]:587 encrypt /etc/postfix/sasl_passwd contains lines like senderN@domain0 login0@domain0:password and [gmail-smtp.l.google.com]:587 login1@domain1:password [smtp.dreamhost.com]:587 longin2@domain2:password /etc/postfix/sender_relay contains lines like senderN@domain0 [gmail-smtp.l.google.com]:587 sender1@domain1 [smtp.dreamhost.com]:587 I've tried in /etc/postfix/smtp_mechs [gmail-smtp.l.google.com]:587 xoauth2 [smtp.dreamhost.com]:587login, plain but that breaks at least google, didn't try dreamhost. -- Henrique
Re: SMTP over IPv6
> out of the box, Postfix will randomly deliver over IPv4 or IPv6 as > both addresses have the same MX preference. > > To try an IPv6 address before IPv4 with the same MX preference, use > "smtp_address_preference = ipv6". But I see no benefits for this > specific case, and it will hinder error recovery in the general > case. I understand the shortcomings of preference = ipv6 and will leave it as 'any'. The part i am still confused about is the perceived behavior difference between inet_interfaces = all inet_interfaces = ipv4, ipv6 Is there something in the code that treats these differently? Or was it just unlucky randomness that made it seem like 'all' favored IPv6 and setting IP's favored IPv4?
Re: Mail system is down
Am 04.01.2022 um 16:25 schrieb Wietse Venema: Alex JOST: Am 04.01.2022 um 02:02 schrieb Ken Wright: $ sudo chmod g+s /usr/sbin/postdrop $ ls -la /usr/sbin/postdrop -r-xr-sr-x 1 postfix postdrop 22808 Sep 7 02:58 /usr/sbin/postdrop Wietse, is this what's expected? AFAICT you are lacking write permission for the user. This program must NOT be writable by users. On my Fedora system the file is owned by root. grep postdrop /etc/postfix/postfix-files $command_directory/postdrop:f:root:$setgid_group:2755:u I just downloaded the postfix package for Ubuntu 20.04 and it's the same. -- Alex JOST
Re: SMTP over IPv6
post...@ptld.com: > The part i am still confused about is the perceived behavior > difference between > >inet_interfaces = all >inet_interfaces = ipv4, ipv6 inet_interfaces takes 'all' or a list of IP addresses. It will also take hostnames but such configuration is fragile; however if you do have hostnames 'ipv6' and 'ipv6' then the above would do something. For the remainder of this response I assume that you mean inet_protocols which takes all, ipv4, and/or ipv6. > Is there something in the code that treats these differently? inet_protocols makes no difference. The inet_interfaces value is converted into a bitmask that does not depend on the order of all, ipv4, and/or ipv6. inet_protocols=ipv4 converts into 1 (2<<0) inet_protocols=ipv6 converts into 2 (2<<1) inet_protocols=all converts into 3 (2<<0 + 2<<1) inet_protocols=ipv4,ipv6 converts into 3 (2<<0 + 2<<1) inet_protocols=ipv6,ipv4 converts into 3 (2<<0 + 2<<1) inet_protocols=all,ipv4,ipv6 converts into 3 (2<<0 + 2<<1) inet_protocols=all,ipv6,ipv4 converts into 3 (2<<0 + 2<<1) and so on for other permutations of the same. Wietse
Re: different mechanism filter for two ISPs
Henrique Martins: > Redirection through google or dreamhost is handle through > relayhost = [gmail-smtp.l.google.com]:587 > smtp_tls_policy_maps = hash:/etc/postfix/tls_policy > smtp_use_tls = yes > smtp_tls_security_level = may > smtp_sasl_auth_enable = yes > smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd > smtp_sasl_security_options = noanonymous > smtp_sasl_tls_security_options = noanonymous > smtp_sender_dependent_authentication = yes > sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay Use sender_dependent_default_transport_maps, and create SMTP delivery transports in master.cf each with their own smtp_sasl_mechanism_filter setting. Wietse
Re: different mechanism filter for two ISPs
Wietse Venema: > Henrique Martins: > > Redirection through google or dreamhost is handle through > > relayhost = [gmail-smtp.l.google.com]:587 > > smtp_tls_policy_maps = hash:/etc/postfix/tls_policy > > smtp_use_tls = yes > > smtp_tls_security_level = may > > smtp_sasl_auth_enable = yes > > smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd > > smtp_sasl_security_options = noanonymous > > smtp_sasl_tls_security_options = noanonymous > > smtp_sender_dependent_authentication = yes > > sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay > > Use sender_dependent_default_transport_maps, and create SMTP delivery > transports in master.cf each with their own smtp_sasl_mechanism_filter > setting. In the lookup result, specify an SMTP delivery transport:host. Postfix expects the same syntax as "default_transport". Wietse
Re: different mechanism filter for two ISPs
wv> Use sender_dependent_default_transport_maps, and create SMTP delivery wv> transports in master.cf each with their own smtp_sasl_mechanism_filter wv> setting. wv> In the lookup result, specify an SMTP delivery transport:host. wv> Postfix expects the same syntax as "default_transport". Thanks! Even though I've been using and messing around with my very simple postfix setup, both from my home and work boxes, I don't think I ever changed anything in master.cf beyond enabling submission. In main.cf: - nulled sender sender_dependent_relayhost_maps - added sender_dependent_default_transport_maps=hash:/etc/postfix/sender_transport Created sender_transport: @domain1 google:[gmail-smtp.l.google.com]:587 @domain2 dreamhost:[smtp.dreamhost.com]:587 Added to master.cf: google unix - - n - - smtp -o smtp_sasl_mechanism_filter=xoauth2 dreamhost unix - - n - - smtp -o smtp_sasl_mechanism_filter=login And that works fine. Took me a bit of time to catch a typo, as I had postifx instead of postfix in the sender_transport path:-) -- Henrique
Fatal: no SASL authentication mechanisms
My Postfix woes continue. Now I'm getting this error message: Jan 4 19:08:47 grace postfix/smtps/smtpd[17286]: fatal: no SASL authentication mechanisms This is starting to get old. Ken
Re: Mail system is down
On Tue, 2022-01-04 at 07:30 -0500, Wietse Venema wrote: > Ken Wright: > > Okay, I ran sudo postfix set-permissions. It ran with no trouble > > whatsoever; no errors, warnings, nothing. Still getting the exact > > same messages in mail.log. > > Then your file system is mounted with 'nosuid' option. Don't do that. I checked /etc/fstab; nothing had the 'nosuid' option.
Re: Fatal: no SASL authentication mechanisms
On 05/01/2022 10:50 am, Ken Wright wrote: > Jan 4 19:08:47 grace postfix/smtps/smtpd[17286]: fatal: no SASL > authentication mechanisms > > This is starting to get old. Posting your running config might get you some help Ken. Expecting good help otherwise may be a long shot. Mal
Re: Mail system is down
Ken Wright: > On Tue, 2022-01-04 at 07:30 -0500, Wietse Venema wrote: > > Ken Wright: > > > Okay, I ran sudo postfix set-permissions.? It ran with no trouble > > > whatsoever; no errors, warnings, nothing.? Still getting the exact > > > same messages in mail.log. > > > > Then your file system is mounted with 'nosuid' option. Don't do that. > > I checked /etc/fstab; nothing had the 'nosuid' option. There is a Linux feature called no_new_privs that prevents a process from gaining privileges for example by running a setuid(setgid) program file. That would cause postdrop and postqueue fail with permission errors. Wietse
Re: Fatal: no SASL authentication mechanisms
On Tue, Jan 04, 2022 at 07:20:43PM -0500, Ken Wright wrote: > My Postfix woes continue. Now I'm getting this error message: > > Jan 4 19:08:47 grace postfix/smtps/smtpd[17286]: fatal: no SASL > authentication mechanisms The selected SASL backend (Cyrus or Dovecot) is not configured to support any usable SASL mechanisms. http://www.postfix.org/DEBUG_README.html#mail Post (in the body of the message, not a "pastebin") the output of: $ postconf -nf and $ postconf -Mf Make sure the message exactly preserves the original line breaks and is not reformatted to add or remove new lines. With "dovecot" authentication, there should be a socket created by "dovecot" that allows Postfix to interact with its authentication service. Relevant logs from "dovecot" may also be helpful. -- Viktor.
Re: Fatal: no SASL authentication mechanisms
On Tue, 2022-01-04 at 20:49 -0500, Viktor Dukhovni wrote:
> On Tue, Jan 04, 2022 at 07:20:43PM -0500, Ken Wright wrote:
>
> > My Postfix woes continue. Now I'm getting this error message:
> >
> > Jan 4 19:08:47 grace postfix/smtps/smtpd[17286]: fatal: no SASL
> > authentication mechanisms
>
> The selected SASL backend (Cyrus or Dovecot) is not configured to
> support any usable SASL mechanisms.
>
> http://www.postfix.org/DEBUG_README.html#mail
>
> Post (in the body of the message, not a "pastebin") the output of:
>
> $ postconf -nf
kwright@grace:~$ postconf -nf
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 0
mailbox_transport = lmtp:unix:private/dovecot-lmtp
milter_default_action = accept
milter_protocol = 6
mydestination = $myhostname, localhost.$mydomain, localhost
myhostname = grace.koalatyworks.com
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
non_smtpd_milters = $smtpd_milters
policyd-spf_time_limit = 3600
readme_directory = no
recipient_delimiter = +
relay_domains = proxy:mysql:/etc/postfix/sql/mysql_relay_domains.cf
relayhost =
smtp_tls_loglevel = 1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_milters = local:opendkim/opendkim.sock
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination, check_policy_service
unix:private/policyd-spf
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
smtpd_tls_cert_file =
/etc/letsencrypt/live/koalatyworks.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/koalatyworks.com/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtputf8_enable = no
transport_maps = proxy:mysql:/etc/postfix/sql/mysql_transport_maps.cf
virtual_alias_maps =
proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf,
proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_maps.cf,
proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_catchall_maps.c
f
virtual_gid_maps = static:2000
virtual_mailbox_base = /var/vmail
virtual_mailbox_domains =
proxy:mysql:/etc/postfix/sql/mysql_virtual_domains_maps.cf
virtual_mailbox_maps =
proxy:mysql:/etc/postfix/sql/mysql_virtual_mailbox_maps.cf,
proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_domain_mailbox_maps.cf
virtual_minimum_uid = 2000
virtual_transport = lmtp:unix:private/dovecot-lmtp
virtual_uid_maps = static:2000
> and
>
> $ postconf -Mf
kwright@grace:~$ postconf -Mf
smtp inet n - y - - smtpd
submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_wrappermode=no
-o smtpd_sasl_auth_enable=yes
-o
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticate
d,reject
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
smtps inet n - y - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticate
d,reject
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
pickup unix n - y 60 1 pickup
cleanupunix n - y - 0 cleanup
qmgr unix n - n 300 1 qmgr
tlsmgr unix - - y 1000? 1 tlsmgr
rewriteunix - - y - - trivial-
rewrite
bounce unix - - y - 0 bounce
defer unix - - y - 0 bounce
trace unix - - y - 0 bounce
verify unix - - y - 1 verify
flush unix n - y 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - y - - smtp
relay unix - - y - - smtp
-o syslog_name=postfix/$service_name
showq unix n - y - - showq
error unix - - y - - error
retry unix
Re: Fatal: no SASL authentication mechanisms
On Tue, Jan 04, 2022 at 09:14:45PM -0500, Ken Wright wrote:
> > > Jan 4 19:08:47 grace postfix/smtps/smtpd[17286]: fatal: no SASL
> > > authentication mechanisms
> >
> > The selected SASL backend (Cyrus or Dovecot) is not configured to
> > support any usable SASL mechanisms.
>
> kwright@grace:~$ postconf -nf
Nothing SASL-related in main.cf. Some relevant defaults are:
smtpd_sasl_mechanism_filter = !external, static:rest
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
These should not result in an empty mechanism list.
> kwright@grace:~$ postconf -Mf
> smtps inet n - y - - smtpd
> -o syslog_name=postfix/smtps
> -o smtpd_tls_wrappermode=yes
> -o smtpd_sasl_auth_enable=yes
> -o
> smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
> -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
> -o smtpd_sasl_type=dovecot
> -o smtpd_sasl_path=private/auth
This looks reasonable, but now you need to actually have a suitable
SASL configuration on the Dovecot side...
Is "Dovecot" configured to create the /var/spool/postfix/private/auth
socket? Did that happen? Is "Dovecot" willing to support the expected
SASL mechanisms (typically "PLAIN")?
I have:
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
}
passdb {
driver = pam
}
There are many other possibilities. Perhaps, instead of doing all the
integration work yourself, you may be better off with a "turnkey" email
server such as ?
--
Viktor.
Re: Fatal: no SASL authentication mechanisms
On Tue, 2022-01-04 at 21:37 -0500, Viktor Dukhovni wrote:
>
> Is "Dovecot" configured to create the /var/spool/postfix/private/auth
> socket? Did that happen? Is "Dovecot" willing to support the
> expected SASL mechanisms (typically "PLAIN")?
>
> I have:
>
> service auth {
> unix_listener /var/spool/postfix/private/auth {
> group = postfix
> mode = 0660
> user = postfix
> }
> }
>
> passdb {
> driver = pam
> }
That's what I have, except my passdb driver is sql. Could that be the
problem?
> There are many other possibilities. Perhaps, instead of doing all
> the integration work yourself, you may be better off with a "turnkey"
> email server such as ?
If I don't do the work, how will I learn?
Ken
Re: Fatal: no SASL authentication mechanisms
On Tue, Jan 04, 2022 at 09:57:55PM -0500, Ken Wright wrote:
> > Is "Dovecot" configured to create the /var/spool/postfix/private/auth
> > socket? Did that happen? Is "Dovecot" willing to support the
> > expected SASL mechanisms (typically "PLAIN")?
> >
> > I have:
> >
> > service auth {
> > unix_listener /var/spool/postfix/private/auth {
> > group = postfix
> > mode = 0660
> > user = postfix
> > }
> > }
> >
> > passdb {
> > driver = pam
> > }
>
> That's what I have, except my passdb driver is sql. Could that be the
> problem?
Hard to say. This is the postfix-users list, but your current issue
looks like it is Dovecot-related. I am not particularly expert in
Dovecot.
> > There are many other possibilities. Perhaps, instead of doing all
> > the integration work yourself, you may be better off with a "turnkey"
> > email server such as ?
>
> If I don't do the work, how will I learn?
You can learn something else... Not everyone need be an expert MTA
operator. Learn Rust programming, Haskell, ARM assembly, ...
--
Viktor.
Re: Fatal: no SASL authentication mechanisms
> That's what I have, except my passdb driver is sql. Could that be the > problem? To test if you have dovecot configured correctly for auth you can use the doveadm tool. Examples: doveadm auth lookup doveadm auth test
Re: Fatal: no SASL authentication mechanisms
> That's what I have, except my passdb driver is sql. Could that be the
> problem?
Following the lines of what Viktor said about creating the auth socket. You
only confirmed you have the service auth{...} in dovecot config. Did you
confirm the socket is being physically created? If there are permission issues
in the directories dovecot will still startup without creating the socket.
[root@host /]# ll /var/spool/postfix/private/auth
srw-rw 1 postfix postfix 0 Jan 4 15:31 /var/spool/postfix/private/auth
Re: Fatal: no SASL authentication mechanisms
On Tue, 2022-01-04 at 22:29 -0500, post...@ptld.com wrote:
> > That's what I have, except my passdb driver is sql. Could that be
> > the problem?
>
>
> Following the lines of what Viktor said about creating the auth socket.
> You only confirmed you have the service auth{...} in dovecot config.
> Did you confirm the socket is being physically created? If there are
> permission issues in the directories dovecot will still startup without
> creating the socket.
>
> [root@host /]# ll /var/spool/postfix/private/auth
> srw-rw 1 postfix postfix 0 Jan 4 15:31
> /var/spool/postfix/private/auth
Here's what I got:
kwright@grace:/etc/dovecot/conf.d$ sudo ls -la
/var/spool/postfix/private/auth
srw-rw 1 postfix postfix 0 Jan 4 19:09
/var/spool/postfix/private/auth
so the socket is there, with read and write permissions for the postfix
user and group.
Ken
Re: Fatal: no SASL authentication mechanisms
On Tue, 2022-01-04 at 21:14 -0500, Ken Wright wrote:
> flags=DRhu
> user=vmail argv=/usr/bin/maildrop -d ${recipient}
> uucp unix - n n - - pipe
> flags=Fqhu
> user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
> ifmail unix - n n - - pipe flags=F
> user=ftn
> argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
> bsmtp unix - n n - - pipe flags=Fq.
> user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender
> $recipient
> scalemail-backend unix - n n - 2 pipe flags=R
> user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store
> ${nexthop}
> ${user} ${extension}
> mailmanunix - n n - - pipe flags=FR
> user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
> ${nexthop}
> ${user}
> policyd-spf unix - n n - 0 spawn
> user=policyd-spf
> argv=/usr/bin/policyd-spf
>
>
Those lines above look debian'ish to me. If you are running debian,
then make sure you have libsasl2-2, libsasl2-modules and libsasl2-
modules-db installed.
-Jim P.
Re: Fatal: no SASL authentication mechanisms
On Tue, 2022-01-04 at 22:58 -0500, Jim Popovitch wrote: > Those lines above look debian'ish to me. If you are running debian, > then make sure you have libsasl2-2, libsasl2-modules and libsasl2- > modules-db installed. Definitely debian-ish. Ubuntu. 20.04, to be specific. I checked, and those libsasl packages are installed. Thanks for trying, though. At this point I need all the help I can get! Ken
