[pfx] Re: Intermittent fatal: no SASL authentication mechanisms

[Stuart Armstrong via Postfix-users]

First, why use SASL auth? It needs a database. Have you considered
more scalable alternatives such as TLS client certificates?
Postfix can use certificate fingerprints instead of PKI.

Second, if you must use SASL auth:

What is the authentication backend database query latency? Have you
looked at their logging? Even if the latency is an unrealistic 10ms
then you cannot expect to handle thousands of SASL logins per second.


Thanks for the suggestions, I will look into these when I am back in 2 
weeks.



If a submission process limit of 100 still results in auth server
timeouts, then Postfix is definitely overwhelming the Dovecot auth
server. Have you looked at their logging?

What about the number of Dovecot auth workers? The configured 60
means the auth server can have only 60 database requests in flight
at any point in time. This may not be sufficient to handle the
onslaught.


I am currently adjusting this setting incrementally, I am not a fan of a 
big bang approach. As for dovecot logging, it seems to be oblivious to 
any process/service problems.


As you say, it could simply be ubuntu sending them to /dev/null, will 
check this as well, once I am back.


Thanks,

Stuart

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Intermittent fatal: no SASL authentication mechanisms

[Wietse Venema via Postfix-users]

First, why use SASL auth? It needs a database. Have you considered
more scalable alternatives such as TLS client certificates?
Postfix can use certificate fingerprints instead of PKI.

Second, if you must use SASL auth:

What is the authentication backend database query latency? Have you
looked at their logging? Even if the latency is an unrealistic 10ms
then you cannot expect to handle thousands of SASL logins per second.

If a submission process limit of 100 still results in auth server
timeouts, then Postfix is definitely overwhelming the Dovecot auth
server. Have you looked at their logging?

What about the number of Dovecot auth workers? The configured 60
means the auth server can have only 60 database requests in flight
at any point in time. This may not be sufficient to handle the
onslaught.

Ubuntu is sometimes configured to log warnings separate from
non-warning messages. This is incredibly unhelpful, because people
may forget to look there.

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Intermittent fatal: no SASL authentication mechanisms

[Stuart Armstrong via Postfix-users]

Some feedback.


It may be possible that you're running out of file handles,
either the kernel limit, or the per-process limit.


I did not have time to actively check this.


 postconf "max_use = 10"
 postfix reload
Error fatal: no SASL authentication mechanisms and postfix process exit, 
appeared again.


No other warnings.

Then set the default process limit value to 100:


postconf "default_process_limit = 100"
   postfix reload
Error fatal: no SASL authentication mechanisms and postfix process exit, 
appeared again.


No other warnings.


All the debug logging is causing systemd to drop imprtant information.
I enabled debug logging for 24 hours only on 1 Aug, logging was normal 
before and after.

Ultimately, it may be better to limit the nunber of conections at
the source, on the Kubernetes application side.


This is the crux of the matter and the correct solution. The source will 
be updated at some point in time, this is in process, as I stated in my 
first mail.


For the time being I need to make the mail server work as best as 
possible, given what I have to work with. If it means not accepting the 
odd 100 mails out of 25K+, then so be it.


I have reverted "max_use = 10" back to default and I bumped the default 
process limit up to 200. The active queue became very slow andhad 
collected 4k mail and climbing, by the time I could check on it again.


Stuart
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Intermittent fatal: no SASL authentication mechanisms

[Wietse Venema via Postfix-users]

Wietse Venema via Postfix-users:
> Stuart Armstrong via Postfix-users:
> > Thank you for your response. For clarity, this issue has been present 
> > for several weeks now.
> > 
> > >  warning: SASL: Connect to Dovecot auth socket 'private/auth'
> > >   failed: REASON FOR FAILURE HERE
> > I do not have this warning in the logs.
> 
> All the debug logging is causing systemd to drop imprtant information.
> 
> > For submission, maxproc is set to 550 to avoid the following type of 
> > warning:
> > "warning: service "submission" (101) has reached its process limit 
> > "100": new clients may experience noticeable delays."
> 
> And:
> 
> > > Dovecot:
> > >  default_process_limit = 400
> 
> Should that not match the Postfix process limit?

Ignore that.

However consider this dovecot.conf setting:

auth_worker_max_count = 60

According to the Dovecot author, auth workers are used for "blocking
lookups" (in an old example, passdb and userdb lookups from mysql).

That number may cause the timeouts on the Postfix side when Postfix
overwhelms the workers.

Of course, increasing that number just moves the bottleneck to the
next service, the mysql (or whatever) userdb or passdb backend.

Ultimately, it may be better to limit the nunber of conections at
the source, on the Kubernetes application side.

Wietse

https://dovecot.dovecot.narkive.com/ZYfAA9NU/number-of-auth-process
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Intermittent fatal: no SASL authentication mechanisms

[Wietse Venema via Postfix-users]

Stuart Armstrong via Postfix-users:
> Thank you for your response. For clarity, this issue has been present 
> for several weeks now.
> 
> >  warning: SASL: Connect to Dovecot auth socket 'private/auth'
> > failed: REASON FOR FAILURE HERE
> I do not have this warning in the logs.

All the debug logging is causing systemd to drop imprtant information.

> For submission, maxproc is set to 550 to avoid the following type of 
> warning:
> "warning: service "submission" (101) has reached its process limit 
> "100": new clients may experience noticeable delays."

And:

> > Dovecot:
> >  default_process_limit = 400

Should that not match the Postfix process limit?

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Intermittent fatal: no SASL authentication mechanisms

[Stuart Armstrong via Postfix-users]

Thank you for your response. For clarity, this issue has been present 
for several weeks now.



 warning: SASL: Connect to Dovecot auth socket 'private/auth'
failed: REASON FOR FAILURE HERE

I do not have this warning in the logs.


Can you try these commands:

 postconf "max_use = 10"
 postfix reload
 postconf "default_process_limit = 100"
 postfix reload
I will run the different commands during our morning low load time and 
report the results.

 warning: SASL: Couldn't send handshake: REASON FOR FAILURE HERE

I have not seen this warning either.

It may be worthwhile to search the log for warning: messages.  They
are much more useful than debug logging.


Debug logging was my last resort, last week.:)


How many submission processes are configured to run?


For submission, maxproc is set to 550 to avoid the following type of 
warning:


"warning: service "submission" (101) has reached its process limit 
"100": new clients may experience noticeable delays."



Postfix:
 default_process_limit = 300

Dovecot:
 default_process_limit = 400

It may be possible that you're running out of file handles,
either the kernel limit, or the per-process limit.


I will monitor these.

Thanks,

Stuart

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Intermittent fatal: no SASL authentication mechanisms

[Wietse Venema via Postfix-users]

Stuart Armstrong via Postfix-users:
> Hello,
> 
> Currently our Postfix server is experiencing a problem with intermittent 
> SASL auth problems.

With all the useless debug logging you forgot to include this
important log message:

warning: SASL: Connect to Dovecot auth socket 'private/auth'
failed: REASON FOR FAILURE HERE

Can you try these commands:

postconf "max_use = 10"
postfix reload

I see a potential file handle leak that can result in an unused
connection to the Dovecot auth server, when a connection succeeds
but has other problems. Postfix logs this:

warning: SASL: Couldn't send handshake: REASON FOR FAILURE HERE

It may be worthwhile to search the log for warning: messages.  They
are much more useful than debug logging.

How many submission processes are configured to run?  Each needs a
file handle to talk to the Dovecot auth server.

Postfix:
default_process_limit = 300

Dovecot:
default_process_limit = 400

It may be possible that you're running out of file handles,
either the kernel limit, or the per-process limit.

Does the problem go away with:

postconf "default_process_limit = 100"
postfix reload


Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Intermittent fatal: no SASL authentication mechanisms

[Stuart Armstrong via Postfix-users]

Hello,

Currently our Postfix server is experiencing a problem with intermittent 
SASL auth problems.


This mail server worked well up to a point, when the "fatal: no SASL 
authentication mechanisms" errors started. From this point I started 
researching and changing the mail server configuration with some 
success, but unable to eradicate the problem completely.


The SASL errors appears when the mail queue has only 100 mails incoming 
or when the bursts of 1000+ occur. Which has given me some gray hair 
trying to troubleshoot.


Server performance is good, enough memory and the worst CPU usage I have 
seen, still showed idle at 50% and no IOWAIT.


Dovecot logs, with debug enabled, do not show any errors or logs that 
correlate with the fatal message in the mail log.


As our client base grows, this mail problem will simply become more 
severe. So any assistance will be appreciated.



Main config changes made:

Increased default service counts for Dovecot and Postfix to the current 
values shown in the configs below.


Added auth caching to Dovecot.

Changed the tls_random_reseed_period to stop a problem with an entropy 
shortage for postfix during peak message times.



The server specs:

VM based: 8 CPU with 100% CPU share, 16GB Memory and SSD storage based.


The nature of the workload:

Business communications app hosted on Kubernetes, which sends out email 
notifications for new messages, to users that have activated 
notifications. This can be a steady stream of 1 to 5 messaged per second 
for several ours and then a burst of hundreds to 1.5k messages in the 
span of 1-2 minutes. The connection for these messages, from all client 
instances, goes to postfix/submission.


The mail process in the app, is "dumb" it sends messages as fast as it 
can and does not respond to mail server smtp response codes. Changes to 
this behavior, are in development.



postfix/submission with smtpd -v output snippit, the entire log is 2GB: 
Timeout after xsasl_dovecot_server_connect is shown.


Aug  1 13:16:22 localhost postfix/submission/smtpd[1575570]: 
xsasl_dovecot_server_create: SASL service=smtp, realm=(null)
Aug  1 13:16:22 localhost postfix/submission/smtpd[1575570]: name_mask: 
noanonymous
Aug  1 13:16:22 localhost postfix/submission/smtpd[1575570]: 
xsasl_dovecot_server_connect: Connecting
Aug  1 13:16:32 localhost postfix/submission/smtpd[1575570]: fatal: no 
SASL authentication mechanisms
Aug  1 13:16:33 localhost postfix/master[186920]: warning: process 
/usr/lib/postfix/sbin/smtpd pid 1575570 exit status 1



Postconf -nf output:

address_verify_map = proxy:btree:$data_directory/verify_cache
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
content_filter = smtp-amavis:[127.0.0.1]:10024
default_process_limit = 300
disable_vrfy_command = yes
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 0
maximal_queue_lifetime = 1d
message_size_limit = 31457280
milter_content_timeout = 30s
milter_default_action = accept
minimal_backoff_time = 1500s
mydestination = $myhostname
myhostname = mail.wilix.dev
mynetworks = 127.0.0.0/8 [::1]/128
myorigin = $myhostname
non_smtpd_milters = inet:127.0.0.1:12345
postscreen_access_list = permit_mynetworks
    cidr:/etc/postfix/postscreen_spf_whitelist.cidr
postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_blacklist_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11]*3
    bl.spameatingmonkey.net=127.0.0.2*2 bl.spamcop.net=127.0.0.2
    dnsbl.sorbs.net=127.0.0.[2..15]
postscreen_dnsbl_threshold = 3
postscreen_greet_action = enforce
postscreen_greet_banner = Welcome, please wait...
postscreen_non_smtp_command_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_action = enforce
postscreen_pipelining_enable = yes
proxy_read_maps = proxy:unix:passwd.byname
    proxy:pgsql:/etc/postfix/sql-domains.cf
    proxy:pgsql:/etc/postfix/sql-domain-aliases.cf
    proxy:pgsql:/etc/postfix/sql-aliases.cf
    proxy:pgsql:/etc/postfix/sql-relaydomains.cf
    proxy:pgsql:/etc/postfix/sql-maintain.cf
    proxy:pgsql:/etc/postfix/sql-relay-recipient-verification.cf
    proxy:pgsql:/etc/postfix/sql-sender-login-map.cf
    proxy:pgsql:/etc/postfix/sql-spliteddomains-transport.cf
    proxy:pgsql:/etc/postfix/sql-transport.cf
proxy_write_maps = $smtp_sasl_auth_cache_name $lmtp_sasl_auth_cache_name
    $address_verify_map
readme_directory = no
recipient_delimiter = +
relay_domains = proxy:pgsql:/etc/postfix/sql-relaydomains.cf
smtp_connect_timeout = 15s
smtp_helo_timeout = 60s
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_connection_reuse = yes
smtp_tls_exclude_ciphers = EXPORT, LOW
smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtpd_banner = $myhostname ESMTP
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_milters = 

Re: Fatal: no SASL authentication mechanisms

[Wietse Venema]

Ken Wright:
> > 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 learn by starting with a WORKING system, then making small
changes and verifying after each change that the system still works,
before making the next change.

Postfix works out of the box: it receives mail on port 25 and with
/usr/sbin/sendmail, and it delivers mail to the system mailbox
directory.  

All further changes should be made one at a time, instead of making
all changes an once and then trying to figure out what is broken.

Wietse

Re: Fatal: no SASL authentication mechanisms

[Ken Wright]

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

Re: Fatal: no SASL authentication mechanisms

[Jim Popovitch]

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

[Ken Wright]

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

[postfix]

> 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

[postfix]

> 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

[Viktor Dukhovni]

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

[Ken Wright]

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

[Viktor Dukhovni]

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 <https://mailinabox.email>?

-- 
Viktor.

Re: Fatal: no SASL authentication mechanisms

[Ken Wright]

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   -   -

Re: Fatal: no SASL authentication mechanisms

[Viktor Dukhovni]

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

[Mal]

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

Fatal: no SASL authentication mechanisms

[Ken Wright]

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: fatal: no SASL authentication mechanisms

[Linkcheck]

Thank you for the notification, Bernardo, but that mail server has been 
offline for some time now. It used to be a backup server which is no 
longer required. I left it live for the "benefit" of spammers. :)


--
Dave Stiles

Re: fatal: no SASL authentication mechanisms

[Bernardo Reino]

Hello,

I'm not sure if you'll receive this message, so I send to the list as well.
(and excuse me for top-posting, but this e-mail has no direct relevance to this 
thread..)


Your server is refusing connections on port 25, so this, inter alia, prevents my 
server from sending you the DMARC reports you are requesting.


postfix/smtp[125178]: 1F21A24000E: to=, relay=none, 
delay=38234, delays=38203/0.03/30/0, dsn=4.4.1, status=deferred (connect to  
mail.ssph.co.uk[46.33.129.43]:25: Connection refused)

It would make sense to either fix the server and/or to stop requesting DMARC 
reports:


_dmarc.linkcheck.co.uk. 3600 IN TXT "v=DMARC1; p=reject; pct=100; 
rua=mailto:dmarc-...@linkcheck.co.uk";

Cheers (and good luck).

On Sun, 10 Oct 2021, Linkcheck wrote:

Wietse, thank you for your assistance. I tried removing (separately) 
unix_listener and unix_listener auth-userdb but neither cured the problem so 
they are now both reinstated.


Apart from two connection messages in the log, the three lines I quoted are 
the only ones following a restart and are triggered by a failed attempt to 
send mail on port 587. Nothing else at all.


I was fairly certain I must have upset postfix config in some way so I 
returned to comparing the old and new server configs. I eventually came to...


smtpd_sasl_security_options = noanonymous noplaintext forward_secrecy 
mutual_auth nodictionary


Trial and error led me to recompose the line to...

smtpd_sasl_security_options = noanonymous nodictionary

The impression I got from SASL_README was that these five options would play 
together nicely but obviously not for every implementation (mine included). 
On re-reading the paragraph where smtpd_sasl_security_options was defined I 
also noticed the title, which had escaped me before: "SASL mechanism 
properties". Not very bright of me. Sorry.


Apart from a warning about spamass-milter 'Could not retrieve sendmail macro 
"i"', which I erroneously thought would be fixed by adding a reference to it 
in main.cf under milter_connect_macros (recommended by some online forums), 
and a missing dkim in email headers, which I think I can cope with, all now 
seems to work. Again, thank you for your quick response to my problem.

Re: fatal: no SASL authentication mechanisms

[Linkcheck]

Wietse, thank you for your assistance. I tried removing (separately) 
unix_listener and unix_listener auth-userdb but neither cured the 
problem so they are now both reinstated.


Apart from two connection messages in the log, the three lines I quoted 
are the only ones following a restart and are triggered by a failed 
attempt to send mail on port 587. Nothing else at all.


I was fairly certain I must have upset postfix config in some way so I 
returned to comparing the old and new server configs. I eventually came 
to...


smtpd_sasl_security_options = noanonymous noplaintext forward_secrecy 
mutual_auth nodictionary


Trial and error led me to recompose the line to...

smtpd_sasl_security_options = noanonymous nodictionary

The impression I got from SASL_README was that these five options would 
play together nicely but obviously not for every implementation (mine 
included). On re-reading the paragraph where smtpd_sasl_security_options 
was defined I also noticed the title, which had escaped me before: "SASL 
mechanism properties". Not very bright of me. Sorry.


Apart from a warning about spamass-milter 'Could not retrieve sendmail 
macro "i"', which I erroneously thought would be fixed by adding a 
reference to it in main.cf under milter_connect_macros (recommended by 
some online forums), and a missing dkim in email headers, which I think 
I can cope with, all now seems to work. Again, thank you for your quick 
response to my problem.


--
Dave Stiles

Re: fatal: no SASL authentication mechanisms

[Wietse Venema]

Linkcheck:
> Sorry Wietse, I thought it might be the other way around: postfix
> wasn't picking up the dovecot reference.

There is a real protocol between Postfix and Dovecot. Postfix will
complain when it is unable to speak that protocol with Dovecot, or
when it receives an unexpected response. 

For example, Postfix logs a warning when it is configured to talk
to the auth-userdb socket instead of the auth-client socket. And I
see an auth-userdb socket in your configuration.

I suggest that you start looking for Postfix "warning:" messages.

The protocol messages are also logged with "smtpd -v" in master.cf
(after you change the file, execute "postfix reload"), but this
should not be needed. The existing warnings should be sufficient.

Wietse

Re: fatal: no SASL authentication mechanisms

[Wietse Venema]

Maybe you can ask on the DOVECOT list why DOVECOT isn't providing
Postfix with SASL mechanism names.

Wietse

fatal: no SASL authentication mechanisms

[Linkcheck]

I am setting up a new postfix/dovecot/etc mail server. Apart from a few 
new features, due to new versions, I have copied a similar setup which 
has been running well for several years. A few days ago the new server 
was working, with just a few tweaks required for dkim/dmarc/etc. At that 
stage I rebooted the debian buster server and was no longer able to 
either send or receive mail.


I have spent the past few days trying to fix just one error, as per 
subject. I get the error on both smtpd and submission. I also seem to 
have lost smtp incoming mail - I'm using a test domain which receives a 
lot of spam but that suddenly ceased.


I actually get a triplet of error messages in the logs for every email:

postfix/smtpd[54380]: fatal: no SASL authentication mechanisms
postfix/master[54208]: warning: process /usr/lib/postfix/sbin/smtpd pid 
54380 exit status 1
postfix/master[54208]: warning: /usr/lib/postfix/sbin/smtpd: bad command 
startup -- throttling


I suspect the second two errors are the result of the first.

I have read postfix and dovecot README docs and many online postings 
about this error and none have solved it other than to point out that 
dovecot needs to provide the SASL authentication, which I knew. I have 
checked several file permissions against those postings and against my 
old server and can find no obvious difference.


Can someone help, please? And what other information do you need from me 
- postconf, doveconf etc? File permissions?


--
Dave Stiles

Re: no SASL authentication mechanisms

[niya levi]

On 11/10/15 15:57, Patrick Ben Koetter wrote:
> * niya levi :
>>
>> On 11/10/15 11:49, Patrick Ben Koetter wrote:
>>> * niya levi :
>>>> nano /etc/dovecot/dovecot.conf
>>>>
>>>> service auth {
>>>>   unix_listener /var/spool/postfix/private/auth {
>>>> group = postfix
>>>> mode = 0666
>>>> user = postfix
>>>>   }
>>>> }
>>> No reason to let others read auth data. Make that:
>>>
>>> mode = 0660
>>>
>>>> postconf -n
>>>> broken_sasl_auth_clients = yes 
>>>>
>>>>
>>>> myorigin = $myhostname
>>>> smtpd_sasl_auth_enable = yes
>>>> smtpd_sasl_exceptions_networks = $mynetworks
>>>> smtpd_sasl_local_domain = $myhostname
>>>> smtpd_sasl_path = private/auth
>>>> smtpd_sasl_security_options = noanonymous noplaintext
>>> That's the problem. Your dovecot server only annouces PLAIN as auth 
>>> mechanism
>>> (by default). Modify the smtpd_sasl_security_options like this:
>>>
>>> smtpd_sasl_security_options = noanonymous
>>>
>>> Then try again.
>>>
>>> I suggest to configure your mail server to offer SMTP AUTH on submission 
>>> (587)
>>> only. Enforce TLS on the submission port and PLAIN will be safe to use.
>>>
>>> p@rick
>>>
>>>> Oct 11 10:45:43 testy postfix/smtpd[16760]: 
>>>> xsasl_dovecot_server_mech_filter: skip mechanism: PLAIN
>>>> Oct 11 10:45:43 testy postfix/smtpd[16760]: 
>>>> xsasl_dovecot_server_mech_filter: skip mechanism: LOGIN
>>>> Oct 11 10:45:43 testy postfix/smtpd[16760]: fatal: no SASL authentication 
>>>> mechanisms
>> thanks p@rick
>> have corrected smtpd_sasl_security_options.
>>> I suggest to configure your mail server to offer SMTP AUTH on submission 
>>> (587)
>>> only. Enforce TLS on the submission port and PLAIN will be safe to use.
>> should i change smtpd_sasl_auth_enable = yes to no in main.cf
>> move the rest of the sasl entries in main.cf yo master.cf
> Leave all settings in main.cf and disable smtpd_sasl_auth_enable in main.cf.
> Then turn it on in master.cf in context of the submission service.
>
>> and change the smtpd_tls_auth_only in the submission section in
>> master.cf to yes ?
> yep.
>
> p@rick
>
>
many thanks Patrick

Re: no SASL authentication mechanisms

[Patrick Ben Koetter]

* niya levi :
> 
> 
> On 11/10/15 11:49, Patrick Ben Koetter wrote:
> > * niya levi :
> >> nano /etc/dovecot/dovecot.conf
> >>
> >> service auth {
> >>   unix_listener /var/spool/postfix/private/auth {
> >> group = postfix
> >> mode = 0666
> >> user = postfix
> >>   }
> >> }
> > No reason to let others read auth data. Make that:
> >
> > mode = 0660
> >
> >> postconf -n
> >> broken_sasl_auth_clients = yes 
> >>
> >>
> >> myorigin = $myhostname
> >> smtpd_sasl_auth_enable = yes
> >> smtpd_sasl_exceptions_networks = $mynetworks
> >> smtpd_sasl_local_domain = $myhostname
> >> smtpd_sasl_path = private/auth
> >> smtpd_sasl_security_options = noanonymous noplaintext
> > That's the problem. Your dovecot server only annouces PLAIN as auth 
> > mechanism
> > (by default). Modify the smtpd_sasl_security_options like this:
> >
> > smtpd_sasl_security_options = noanonymous
> >
> > Then try again.
> >
> > I suggest to configure your mail server to offer SMTP AUTH on submission 
> > (587)
> > only. Enforce TLS on the submission port and PLAIN will be safe to use.
> >
> > p@rick
> >
> >> Oct 11 10:45:43 testy postfix/smtpd[16760]: 
> >> xsasl_dovecot_server_mech_filter: skip mechanism: PLAIN
> >> Oct 11 10:45:43 testy postfix/smtpd[16760]: 
> >> xsasl_dovecot_server_mech_filter: skip mechanism: LOGIN
> >> Oct 11 10:45:43 testy postfix/smtpd[16760]: fatal: no SASL authentication 
> >> mechanisms
> thanks p@rick
> have corrected smtpd_sasl_security_options.
> > I suggest to configure your mail server to offer SMTP AUTH on submission 
> > (587)
> > only. Enforce TLS on the submission port and PLAIN will be safe to use.
> should i change smtpd_sasl_auth_enable = yes to no in main.cf
> move the rest of the sasl entries in main.cf yo master.cf

Leave all settings in main.cf and disable smtpd_sasl_auth_enable in main.cf.
Then turn it on in master.cf in context of the submission service.

> and change the smtpd_tls_auth_only in the submission section in
> master.cf to yes ?

yep.

p@rick


-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
 

Re: no SASL authentication mechanisms

[niya levi]

On 11/10/15 11:49, Patrick Ben Koetter wrote:
> * niya levi :
>> nano /etc/dovecot/dovecot.conf
>>
>> service auth {
>>   unix_listener /var/spool/postfix/private/auth {
>> group = postfix
>> mode = 0666
>> user = postfix
>>   }
>> }
> No reason to let others read auth data. Make that:
>
> mode = 0660
>
>> postconf -n
>> broken_sasl_auth_clients = yes   
>>  
>>
>> myorigin = $myhostname
>> smtpd_sasl_auth_enable = yes
>> smtpd_sasl_exceptions_networks = $mynetworks
>> smtpd_sasl_local_domain = $myhostname
>> smtpd_sasl_path = private/auth
>> smtpd_sasl_security_options = noanonymous noplaintext
> That's the problem. Your dovecot server only annouces PLAIN as auth mechanism
> (by default). Modify the smtpd_sasl_security_options like this:
>
> smtpd_sasl_security_options = noanonymous
>
> Then try again.
>
> I suggest to configure your mail server to offer SMTP AUTH on submission (587)
> only. Enforce TLS on the submission port and PLAIN will be safe to use.
>
> p@rick
>
>> Oct 11 10:45:43 testy postfix/smtpd[16760]: 
>> xsasl_dovecot_server_mech_filter: skip mechanism: PLAIN
>> Oct 11 10:45:43 testy postfix/smtpd[16760]: 
>> xsasl_dovecot_server_mech_filter: skip mechanism: LOGIN
>> Oct 11 10:45:43 testy postfix/smtpd[16760]: fatal: no SASL authentication 
>> mechanisms
thanks p@rick
have corrected smtpd_sasl_security_options.
> I suggest to configure your mail server to offer SMTP AUTH on submission (587)
> only. Enforce TLS on the submission port and PLAIN will be safe to use.
should i change smtpd_sasl_auth_enable = yes to no in main.cf
move the rest of the sasl entries in main.cf yo master.cf
and change the smtpd_tls_auth_only in the submission section in
master.cf to yes ?

shadrock

Re: no SASL authentication mechanisms

[Patrick Ben Koetter]

* niya levi :
> nano /etc/dovecot/dovecot.conf
> 
> service auth {
>   unix_listener /var/spool/postfix/private/auth {
> group = postfix
> mode = 0666
> user = postfix
>   }
> }

No reason to let others read auth data. Make that:

mode = 0660

> postconf -n
> broken_sasl_auth_clients = yes
>   
>  
> myorigin = $myhostname
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_exceptions_networks = $mynetworks
> smtpd_sasl_local_domain = $myhostname
> smtpd_sasl_path = private/auth
> smtpd_sasl_security_options = noanonymous noplaintext

That's the problem. Your dovecot server only annouces PLAIN as auth mechanism
(by default). Modify the smtpd_sasl_security_options like this:

smtpd_sasl_security_options = noanonymous

Then try again.

I suggest to configure your mail server to offer SMTP AUTH on submission (587)
only. Enforce TLS on the submission port and PLAIN will be safe to use.

p@rick

> Oct 11 10:45:43 testy postfix/smtpd[16760]: xsasl_dovecot_server_mech_filter: 
> skip mechanism: PLAIN
> Oct 11 10:45:43 testy postfix/smtpd[16760]: xsasl_dovecot_server_mech_filter: 
> skip mechanism: LOGIN
> Oct 11 10:45:43 testy postfix/smtpd[16760]: fatal: no SASL authentication 
> mechanisms

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
 

no SASL authentication mechanisms

[niya levi]

hi everyone
i have postfix dovecot and postgresql installed on arch linux,
the server delivers mail correctly without sasl enabled
when i setup and enable sasl and telnet from localhost or from a remote
connection
i get 'Connection closed by foreign host' immediately
and i get in the logs
no SASL authentication mechanisms
these are my configuration files and logs.

nano /etc/dovecot/dovecot.conf

disable_plaintext_auth = no
mail_privileged_group = vmail
log_timestamp = "%Y-%m-%d %H:%M:%S "

log_path = /var/log/dovecot.log
#  enables logging all failed authentication attempts.
# auth_verbose=yes
# enables all authentication debug logging (also enables auth_verbose).
Passwords are logged as .
# auth_debug=yes
# does everything that auth_debug=yes does, but it also removes password
hiding.
auth_debug_passwords=yes
# enables all kinds of mail related debug logging, such as showing where
Dovecot is looking for mails.
mail_debug=yes
# enables logging SSL errors and warnings. Even without this setting if
connection is closed because of an SSL error, the error is logged as the
disconnection reason (v1.1+)
# verbose_ssl=yes

passdb {
  args = /etc/dovecot/dovecot-sql.conf
  driver = sql
}
userdb {
  driver = prefetch
}
userdb {
  args = /etc/dovecot/dovecot-sql.conf
  driver = sql
}

protocols = "pop3 imap lmtp"

protocol imap {
  mail_plugins = " autocreate"
}

plugin {
  autocreate = Trash
  autocreate2 = Sent
  autosubscribe = Trash
  autosubscribe2 = Sent
}

service auth {
  unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0666
user = postfix
  }
}

service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0600
user = postfix
}
}
protocol lmtp {
postmaster_address=postmas...@testy.tissisat.co.uk
hostname=testy.tissisat.co.uk
info_log_path = /var/log/dovecot-lmtp.log
}

ssl_cert = 
localhost.localdomain[127.0.0.1]: 220 testy.tissisat.co.uk ESMTP Postfix
Oct 11 10:45:43 testy postfix/smtpd[16760]: xsasl_dovecot_server_create:
SASL service=smtp, realm=testy.tissisat.co.uk
Oct 11 10:45:43 testy postfix/smtpd[16760]: name_mask: noanonymous
Oct 11 10:45:43 testy postfix/smtpd[16760]: name_mask: noplaintext
Oct 11 10:45:43 testy postfix/smtpd[16760]:
xsasl_dovecot_server_connect: Connecting
Oct 11 10:45:43 testy postfix/smtpd[16760]:
xsasl_dovecot_server_connect: auth reply: VERSION?1?1
Oct 11 10:45:43 testy postfix/smtpd[16760]:
xsasl_dovecot_server_connect: auth reply: MECH?PLAIN?plaintext
Oct 11 10:45:43 testy postfix/smtpd[16760]: name_mask: plaintext
Oct 11 10:45:43 testy postfix/smtpd[16760]:
xsasl_dovecot_server_connect: auth reply: MECH?LOGIN?plaintext
Oct 11 10:45:43 testy postfix/smtpd[16760]: name_mask: plaintext
Oct 11 10:45:43 testy postfix/smtpd[16760]:
xsasl_dovecot_server_connect: auth reply: SPID?16763
Oct 11 10:45:43 testy postfix/smtpd[16760]:
xsasl_dovecot_server_connect: auth reply: CUID?1
Oct 11 10:45:43 testy postfix/smtpd[16760]:
xsasl_dovecot_server_connect: auth reply:
COOKIE?5144cccf9d947e85a107922ec961648c
Oct 11 10:45:43 testy postfix/smtpd[16760]:
xsasl_dovecot_server_connect: auth reply: DONE
Oct 11 10:45:43 testy postfix/smtpd[16760]:
xsasl_dovecot_server_mech_filter: skip mechanism: PLAIN
Oct 11 10:45:43 testy postfix/smtpd[16760]:
xsasl_dovecot_server_mech_filter: skip mechanism: LOGIN
Oct 11 10:45:43 testy postfix/smtpd[16760]: fatal: no SASL
authentication mechanisms
Oct 11 10:45:44 testy postfix/master[396]: warning: process
/usr/lib/postfix/bin/smtpd pid 16760 exit status 1
Oct 11 10:45:44 testy postfix/master[396]: warning:
/usr/lib/postfix/bin/smtpd: bad command startup -- throttling


Shadrock

Re: fatal: no SASL authentication mechanisms

[Benny Pedersen]

Edgar Pettijohn skrev den 2015-01-18 15:07:


I think its default in a lot of distros.  I know it is in openbsd and
I'm pretty sure freebsd also.


its not so in gentoo, living on edge ? :=)

Re: fatal: no SASL authentication mechanisms

[Benny Pedersen]

James Lockie skrev den 2015-01-18 05:40:

On 01/17/15 22:55, Viktor Dukhovni wrote:

On Sat, Jan 17, 2015 at 10:51:30PM -0500, James Lockie wrote:


/var/log/mail.log
postfix/smtpd[1519]: warning: SASL: Connect to 
/var/spool/postfix/private/auth failed: No such file or directory


/etc/postfix/master.cf
submission inet n   -   -   -   -   smtpd -v
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

Just another chroot victim,


Oh.
Is Postfix and/or Dovecot chrooted by default?
Can a message be output in the info log?


you already see it in verbose logs ?

submission inet n   -   n   -   -   smtpd
   

i have never seen a problem with dovecot

just dont use - as default wish list

Re: chroot defaults (was: fatal: no SASL authentication mechanisms)

[James Lockie]

On 01/18/15 10:57, Wietse Venema wrote:
>> better make a bugreport at your distribution
>> https://www.google.at/search?q=postfix+debian+chroot+problems
> Scott K:
>> Assuming this is Debian, there's no bug report needed. It's an
>> intentional maintainer choice and not a bug.
> Edgar Pettijohn:
>> I think its default in a lot of distros.  I know it is in openbsd and 
>> I'm pretty sure freebsd also.
> With the upcoming stable release(*), the built-in chroot is "no"
> by default.  However, a built-in backwards-compatibility safety net
> will preserve past Postfix behavior, so if the maintainers get it
> right, then you get to decide if you like the new defaults, not the
> maintainers.
>
> http://www.postfix.org/COMPATIBILITY_README.html
>
> *I expect to issue "release candidates" in a week or so.
>
>   Wietse
>
Thanks everyone that replied,
It seems to work reliably now.

chroot defaults (was: fatal: no SASL authentication mechanisms)

[Wietse Venema]

> better make a bugreport at your distribution
> https://www.google.at/search?q=postfix+debian+chroot+problems

Scott K:
> Assuming this is Debian, there's no bug report needed. It's an
> intentional maintainer choice and not a bug.

Edgar Pettijohn:
> I think its default in a lot of distros.  I know it is in openbsd and 
> I'm pretty sure freebsd also.

With the upcoming stable release(*), the built-in chroot is "no"
by default.  However, a built-in backwards-compatibility safety net
will preserve past Postfix behavior, so if the maintainers get it
right, then you get to decide if you like the new defaults, not the
maintainers.

http://www.postfix.org/COMPATIBILITY_README.html

*I expect to issue "release candidates" in a week or so.

Wietse

Re: fatal: no SASL authentication mechanisms

[James Lockie]

On 01/18/15 10:03, Edgar Pettijohn wrote:
>
> On 01/18/15 08:55, James Lockie wrote:
>> On 01/18/15 09:07, Edgar Pettijohn wrote:
> better make a bugreport at your distribution
> https://www.google.at/search?q=postfix+debian+chroot+problems
 Assuming this is Debian, there's no bug report needed. It's an intentional 
 maintainer choice and not a bug.

 Scott K

>>> I think its default in a lot of distros.  I know it is in openbsd and I'm 
>>> pretty sure freebsd also.
>>>
>> What would cause the "warning: SASL: Connect to 
>> /var/spool/postfix/private/auth failed: No such file or directory" to come 
>> back after working for a while?
>> I had to restart dovecot and  postfix,
>> Is there any postfix debug tool like doveadm that I can run to test 
>> authentication?
> I think what it comes down to is if you have turned off chroot or not.  If 
> not you need to think about the following lines:
>
> /etc/postfix/main.cf
> smtpd_sasl_type = dovecot
> smtpd_sasl_path = /var/spool/postfix/private/auth
>
> Because if you are chroot its really looking for 
> /var/spool/postfix/var/spool/postfix/private/auth which doesn't exist most 
> likely.
>
I turned off chroot, that is why it works for a while. :-(

Re: fatal: no SASL authentication mechanisms

[Edgar Pettijohn]

On 01/18/15 08:55, James Lockie wrote:

On 01/18/15 09:07, Edgar Pettijohn wrote:

better make a bugreport at your distribution
https://www.google.at/search?q=postfix+debian+chroot+problems

Assuming this is Debian, there's no bug report needed. It's an intentional 
maintainer choice and not a bug.

Scott K


I think its default in a lot of distros.  I know it is in openbsd and I'm 
pretty sure freebsd also.


What would cause the "warning: SASL: Connect to /var/spool/postfix/private/auth 
failed: No such file or directory" to come back after working for a while?
I had to restart dovecot and  postfix,
Is there any postfix debug tool like doveadm that I can run to test 
authentication?
I think what it comes down to is if you have turned off chroot or not.  
If not you need to think about the following lines:


/etc/postfix/main.cf
smtpd_sasl_type = dovecot
smtpd_sasl_path = /var/spool/postfix/private/auth

Because if you are chroot its really looking for 
/var/spool/postfix/var/spool/postfix/private/auth which doesn't exist 
most likely.

Re: fatal: no SASL authentication mechanisms

[Patrick Ben Koetter]

* James Lockie :
> 
> On 01/18/15 09:07, Edgar Pettijohn wrote:
> >
> >>> better make a bugreport at your distribution
> >>> https://www.google.at/search?q=postfix+debian+chroot+problems
> >> Assuming this is Debian, there's no bug report needed. It's an intentional 
> >> maintainer choice and not a bug.
> >>
> >> Scott K
> >>
> > I think its default in a lot of distros.  I know it is in openbsd and I'm 
> > pretty sure freebsd also.
> >
> What would cause the "warning: SASL: Connect to 
> /var/spool/postfix/private/auth failed: No such file or directory" to come 
> back after working for a while?
> I had to restart dovecot and  postfix,
> Is there any postfix debug tool like doveadm that I can run to test 
> authentication?

Sure, read the docs out there. There's plenty of them. Start at the Postfix
Website in the section about debugging.

p@rick



-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
 

Re: fatal: no SASL authentication mechanisms

[James Lockie]

On 01/18/15 09:07, Edgar Pettijohn wrote:
>
>>> better make a bugreport at your distribution
>>> https://www.google.at/search?q=postfix+debian+chroot+problems
>> Assuming this is Debian, there's no bug report needed. It's an intentional 
>> maintainer choice and not a bug.
>>
>> Scott K
>>
> I think its default in a lot of distros.  I know it is in openbsd and I'm 
> pretty sure freebsd also.
>
What would cause the "warning: SASL: Connect to /var/spool/postfix/private/auth 
failed: No such file or directory" to come back after working for a while?
I had to restart dovecot and  postfix,
Is there any postfix debug tool like doveadm that I can run to test 
authentication?

Re: fatal: no SASL authentication mechanisms

[Edgar Pettijohn]

better make a bugreport at your distribution
https://www.google.at/search?q=postfix+debian+chroot+problems

Assuming this is Debian, there's no bug report needed. It's an intentional 
maintainer choice and not a bug.

Scott K

I think its default in a lot of distros.  I know it is in openbsd and 
I'm pretty sure freebsd also.

Re: fatal: no SASL authentication mechanisms

[li...@rhsoft.net]

Am 18.01.2015 um 06:14 schrieb Viktor Dukhovni:

On Sun, Jan 18, 2015 at 12:02:24AM -0500, Scott Kitterman wrote:

better make a bugreport at your distribution
https://www.google.at/search?q=postfix+debian+chroot+problems


Assuming this is Debian, there's no bug report needed. It's an intentional 
maintainer choice and not a bug.


I think the "intentional maintainer choice" has long proved unwise.
So though not a bug, it is definitely misfeature.  Since the default
chroot is far from seamless:

 - Lost logs
 - Milter socket problems
 - SASL problems
 - DNS resolution problems
 - ...

If the level of integration were such that none of these issues
were to ever happen, I'd accept this as a valid maintainer choice.
Given that problems come up all the time, I rather see this is a
maintainer mistake that should finally be corrected.

Chroot is for experts willing and able to figure out what needs to
be done to get it working.  As a default Debian/Ubuntu configuration
I think it just needlessly gives Postfix on these systems a bad
name.


that's all true

but if each and every day a new user opens a fresh bugreport claiming 
the defualts are broken and stupid over the time the "intentional 
maintainer choice" may change


that won't happen by explain the same porblem on that list each week
__

honestly postfix is not completly innocent because the internal default 
should be "no" for "-" instead "yes", i saw way too much people believe 
it's disabled untill someone explained that this is only the case with 
an explicit "n"


having it enabled builtin but with the shipped default config disabled 
is not really the best way to explain people it's a bad idea enable it 
until you know exactly what you are doing

Re: fatal: no SASL authentication mechanisms

[Viktor Dukhovni]

On Sun, Jan 18, 2015 at 12:02:24AM -0500, Scott Kitterman wrote:

> >better make a bugreport at your distribution
> >https://www.google.at/search?q=postfix+debian+chroot+problems
> 
> Assuming this is Debian, there's no bug report needed. It's an intentional 
> maintainer choice and not a bug.

I think the "intentional maintainer choice" has long proved unwise.
So though not a bug, it is definitely misfeature.  Since the default
chroot is far from seamless:

- Lost logs
- Milter socket problems
- SASL problems
- DNS resolution problems
- ...

If the level of integration were such that none of these issues
were to ever happen, I'd accept this as a valid maintainer choice.
Given that problems come up all the time, I rather see this is a
maintainer mistake that should finally be corrected.

Chroot is for experts willing and able to figure out what needs to
be done to get it working.  As a default Debian/Ubuntu configuration
I think it just needlessly gives Postfix on these systems a bad
name.

-- 
Viktor.

Re: fatal: no SASL authentication mechanisms

[Scott Kitterman]

On January 17, 2015 11:58:16 PM EST, "li...@rhsoft.net"  
wrote:
>
>Am 18.01.2015 um 05:40 schrieb James Lockie:
>> On 01/17/15 22:55, Viktor Dukhovni wrote:
>>> On Sat, Jan 17, 2015 at 10:51:30PM -0500, James Lockie wrote:
>>>
 /var/log/mail.log
 postfix/smtpd[1519]: warning: SASL: Connect to
>/var/spool/postfix/private/auth failed: No such file or directory

 /etc/postfix/master.cf
 submission inet n   -   -   -   -   smtpd -v
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
>>> Just another chroot victim,
>>>
>> Is Postfix and/or Dovecot chrooted by default?
>
>no, the default in master.cf is an explicit "n"
>
>> Can a message be output in the info log?
>
>better make a bugreport at your distribution
>https://www.google.at/search?q=postfix+debian+chroot+problems

Assuming this is Debian, there's no bug report needed. It's an intentional 
maintainer choice and not a bug.

Scott K

Re: fatal: no SASL authentication mechanisms

[li...@rhsoft.net]

Am 18.01.2015 um 05:40 schrieb James Lockie:

On 01/17/15 22:55, Viktor Dukhovni wrote:

On Sat, Jan 17, 2015 at 10:51:30PM -0500, James Lockie wrote:


/var/log/mail.log
postfix/smtpd[1519]: warning: SASL: Connect to /var/spool/postfix/private/auth 
failed: No such file or directory

/etc/postfix/master.cf
submission inet n   -   -   -   -   smtpd -v
   -o smtpd_tls_security_level=encrypt
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
   -o milter_macro_daemon_name=ORIGINATING

Just another chroot victim,


Is Postfix and/or Dovecot chrooted by default?


no, the default in master.cf is an explicit "n"


Can a message be output in the info log?


better make a bugreport at your distribution
https://www.google.at/search?q=postfix+debian+chroot+problems

Re: fatal: no SASL authentication mechanisms

[James Lockie]

On 01/17/15 22:55, Viktor Dukhovni wrote:
> On Sat, Jan 17, 2015 at 10:51:30PM -0500, James Lockie wrote:
>
>> /var/log/mail.log
>> postfix/smtpd[1519]: warning: SASL: Connect to 
>> /var/spool/postfix/private/auth failed: No such file or directory
>>
>> /etc/postfix/master.cf
>> submission inet n   -   -   -   -   smtpd -v
>>   -o smtpd_tls_security_level=encrypt
>>   -o smtpd_sasl_auth_enable=yes
>>   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
>>   -o milter_macro_daemon_name=ORIGINATING
> Just another chroot victim,
>
Oh.
Is Postfix and/or Dovecot chrooted by default?
Can a message be output in the info log?

Re: fatal: no SASL authentication mechanisms

[Viktor Dukhovni]

On Sat, Jan 17, 2015 at 10:51:30PM -0500, James Lockie wrote:

> /var/log/mail.log
> postfix/smtpd[1519]: warning: SASL: Connect to 
> /var/spool/postfix/private/auth failed: No such file or directory
> 
> /etc/postfix/master.cf
> submission inet n   -   -   -   -   smtpd -v
>   -o smtpd_tls_security_level=encrypt
>   -o smtpd_sasl_auth_enable=yes
>   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
>   -o milter_macro_daemon_name=ORIGINATING

Just another chroot victim,

-- 
Viktor.

fatal: no SASL authentication mechanisms

[James Lockie]

I need help with using dovecot sasl.
I get /var/spool/postfix/private/auth failed: No such file or directory but the 
file exists.

# ls -l /var/spool/postfix/private/auth
srw-rw-rw- 1 postfix postfix 0 Jan 17 21:58 /var/spool/postfix/private/auth


I've verified docotsasl works (I think):
# doveadm auth -a /var/spool/postfix/private/auth test_user
Password:
passdb: test_user auth succeeded
extra fields:
  user=test_user


These are the relevant log entries:
/var/log/mail.err
postfix/smtpd[1704]: fatal: no SASL authentication mechanisms

/var/log/mail.log
postfix/smtpd[1519]: warning: SASL: Connect to /var/spool/postfix/private/auth 
failed: No such file or directory

/etc/postfix/master.cf
submission inet n   -   -   -   -   smtpd -v
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

/etc/postfix/main.cf
smtpd_sasl_type = dovecot
smtpd_sasl_path = /var/spool/postfix/private/auth
smtpd_sasl_auth_enable = yes
#smtpd_sasl_security_options = noanonymous
#smtpd_sasl_local_domain =
smtpd_recipient_restrictions = 
permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination

Re: fatal: no SASL authentication mechanisms

[Noel Jones]

On 1/29/2013 12:13 PM, FigureoTV SFM wrote:
> On Sun, Jan 27, 2013 at 12:05 PM, Erwan David  wrote:
>> Le 27/01/2013 16:14, FigureoTV SFM a écrit :
>>
>>> Hello.
>>>
>>> I'm a postfix newbie and experiencing a lot of problems trying to get
>>> to run smoothly as it was on my previous server.
>>>
>>> I don't know what's causing these errors:
>>>
>>> Jan 27 15:07:40 hawk084 postfix/smtpd[13897]: connect from
>>> unknown[190.80.213.58]
>>> Jan 27 15:07:40 hawk084 postfix/smtpd[13897]: warning: SASL: Connect
>>> to private/auth failed: Connection refused
>>
>> First error is here, following ones are consequences.
>>
>>> I'm not using any password authentication method and got that fatal error.
>>>
>>> I can't receive or send mail.
>>>
>>> What am I doing wrong?
>>
>>
>> You configured postfix to use SASL, through a socket that it cannot open.
>> You should review your SASL configuration.
>>
> 
> I still can't solve this problem. I don't know why is SASL is being
> used and I'm not doing any authentication.
> 


Postfix is using SASL because you told it to.
http://www.postfix.org/postconf.5.html#smtpd_sasl_auth_enable

Maybe you can turn it off with the commands

postconf -e smtpd_sasl_auth_enable=no
postfix reload

Re: fatal: no SASL authentication mechanisms

[FigureoTV SFM]

On Sun, Jan 27, 2013 at 12:05 PM, Erwan David  wrote:
> Le 27/01/2013 16:14, FigureoTV SFM a écrit :
>
>> Hello.
>>
>> I'm a postfix newbie and experiencing a lot of problems trying to get
>> to run smoothly as it was on my previous server.
>>
>> I don't know what's causing these errors:
>>
>> Jan 27 15:07:40 hawk084 postfix/smtpd[13897]: connect from
>> unknown[190.80.213.58]
>> Jan 27 15:07:40 hawk084 postfix/smtpd[13897]: warning: SASL: Connect
>> to private/auth failed: Connection refused
>
> First error is here, following ones are consequences.
>
>> I'm not using any password authentication method and got that fatal error.
>>
>> I can't receive or send mail.
>>
>> What am I doing wrong?
>
>
> You configured postfix to use SASL, through a socket that it cannot open.
> You should review your SASL configuration.
>

I still can't solve this problem. I don't know why is SASL is being
used and I'm not doing any authentication.

Re: fatal: no SASL authentication mechanisms

[Jerry]

On Sun, 27 Jan 2013 11:58:45 -0400
FigureoTV SFM articulated:

> Links broken.

1) Please don't "top post".

2) The links are working fine here.

-- 
Jerry ✌
postfix-u...@seibercom.net
_
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Re: fatal: no SASL authentication mechanisms

[Erwan David]

Le 27/01/2013 16:14, FigureoTV SFM a écrit :

Hello.

I'm a postfix newbie and experiencing a lot of problems trying to get
to run smoothly as it was on my previous server.

I don't know what's causing these errors:

Jan 27 15:07:40 hawk084 postfix/smtpd[13897]: connect from
unknown[190.80.213.58]
Jan 27 15:07:40 hawk084 postfix/smtpd[13897]: warning: SASL: Connect
to private/auth failed: Connection refused

First error is here, following ones are consequences.

I'm not using any password authentication method and got that fatal error.

I can't receive or send mail.

What am I doing wrong?


You configured postfix to use SASL, through a socket that it cannot 
open. You should review your SASL configuration.

Re: fatal: no SASL authentication mechanisms

[FigureoTV SFM]

Links broken.


hawk084:~# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
inet_interfaces = all
mail_owner = postfix
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
maximal_backoff_time = 2000
minimal_backoff_time = 500
mydestination = owsmail.optimumwireless.com,
localhost.optimumwireless.com, localhost
myhostname = owsmail.optimumwireless.com
mynetworks = x.x.x.x/xx
myorigin = /etc/mailname
queue_run_delay = 500
readme_directory = no
receive_override_options = no_address_mappings
recipient_delimiter = +
relayhost =
smtp_helo_timeout = 60
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_connection_rate_limit = 500
smtpd_recipient_restrictions = permit_mynetworks
permit_sasl_authenticated   reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_cert_file = /etc/ssl/certs/postfix.pem
smtpd_tls_key_file = /etc/ssl/private/postfix.pem
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
soft_bounce = yes
virtual_alias_maps =
mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_transport = dovecot


On Sun, Jan 27, 2013 at 11:46 AM, Jerry  wrote:
> On Sun, 27 Jan 2013 11:14:48 -0400
> FigureoTV SFM articulated:
>
>> Hello.
>>
>> I'm a postfix newbie and experiencing a lot of problems trying to get
>> to run smoothly as it was on my previous server.
>
> http://www.postfix.com/DEBUG_README.html#mail
>
> Specifically:
>
> Output from "postconf -n". Please do not send your main.cf file, or
> 500+ lines of postconf output.
>
> Better, provide output from the postfinger tool. This can be found at
> http://ftp.wl0.org/SOURCES/postfinger.
>
> If the problem is SASL related, consider including the output from the
> saslfinger tool. This can be found at
> http://postfix.state-of-mind.de/patrick.koetter/saslfinger/.
>
> --
> Jerry ✌
> postfix-u...@seibercom.net
> _
> TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
> TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Re: fatal: no SASL authentication mechanisms

[Jerry]

On Sun, 27 Jan 2013 11:14:48 -0400
FigureoTV SFM articulated:

> Hello.
> 
> I'm a postfix newbie and experiencing a lot of problems trying to get
> to run smoothly as it was on my previous server.

http://www.postfix.com/DEBUG_README.html#mail

Specifically:

Output from "postconf -n". Please do not send your main.cf file, or
500+ lines of postconf output.

Better, provide output from the postfinger tool. This can be found at
http://ftp.wl0.org/SOURCES/postfinger.

If the problem is SASL related, consider including the output from the
saslfinger tool. This can be found at
http://postfix.state-of-mind.de/patrick.koetter/saslfinger/.

-- 
Jerry ✌
postfix-u...@seibercom.net
_
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

fatal: no SASL authentication mechanisms

[FigureoTV SFM]

Hello.

I'm a postfix newbie and experiencing a lot of problems trying to get
to run smoothly as it was on my previous server.

I don't know what's causing these errors:

Jan 27 15:07:40 hawk084 postfix/smtpd[13897]: connect from
unknown[190.80.213.58]
Jan 27 15:07:40 hawk084 postfix/smtpd[13897]: warning: SASL: Connect
to private/auth failed: Connection refused
Jan 27 15:07:40 hawk084 postfix/smtpd[13897]: fatal: no SASL
authentication mechanisms
Jan 27 15:07:41 hawk084 postfix/master[17615]: warning: process
/usr/lib/postfix/smtpd pid 13896 exit status 1
Jan 27 15:07:41 hawk084 postfix/master[17615]: warning:
/usr/lib/postfix/smtpd: bad command startup -- throttling
Jan 27 15:07:41 hawk084 postfix/master[17615]: warning: process
/usr/lib/postfix/smtpd pid 13897 exit status 1
Jan 27 15:08:41 hawk084 postfix/smtpd[13914]: connect from
mail-qc0-f200.google.com[209.85.216.200]
Jan 27 15:08:41 hawk084 postfix/smtpd[13914]: warning: SASL: Connect
to private/auth failed: Connection refused
Jan 27 15:08:41 hawk084 postfix/smtpd[13914]: fatal: no SASL
authentication mechanisms
Jan 27 15:08:42 hawk084 postfix/master[17615]: warning: process
/usr/lib/postfix/smtpd pid 13914 exit status 1
Jan 27 15:08:42 hawk084 postfix/master[17615]: warning:
/usr/lib/postfix/smtpd: bad command startup -- throttling

I'm not using any password authentication method and got that fatal error.

I can't receive or send mail.

What am I doing wrong?

Re: Fatal: No SASL Authentication Mechanisms Error

[Wietse Venema]

Shalom Levytam:
> Hi,
> 
> I'm trying to configure a new server with postfix 2.6.6 and dovecot 2.0. 
> My previous servers have all been dovecot 1.x. Trying to port over my
> previous configurations has been a real headache.
> 
> Currently, I'm getting the following errors when trying to connect with:
> openssl s_client -starttls smtp -connect localhost:25
> 
> Aug 21 19:08:46 localhost postfix/smtpd[26252]: connect from localhost[::1]
> Aug 21 19:08:46 localhost postfix/smtpd[26252]: warning: SASL: Connect to
> private/auth failed: Permission denied
> Aug 21 19:08:46 localhost postfix/smtpd[26252]: fatal: no SASL
> authentication mechanisms
> Aug 21 19:08:47 localhost postfix/master[26226]: warning: process
> /usr/libexec/postfix/smtpd pid 26252 exit status 1
> Aug 21 19:08:47 localhost postfix/master[26226]: warning:
> /usr/libexec/postfix/smtpd: bad command startup -- throttling
> 
> The private/auth file gets recreated if I delete it and restart
> dovecot.  The permissions are postfix:postfix.  The private dir's
> permissions are postfix:root.
>
> If someone could help me out I'd really appreciate it.  My Dovecot and
> Postfix configuration changes are below...

Turn off SELINUX, APPARMOR, etc., or update their rules.

Wietse

Fatal: No SASL Authentication Mechanisms Error

[Shalom Levytam]

Hi,

I'm trying to configure a new server with postfix 2.6.6 and dovecot 2.0. 
My previous servers have all been dovecot 1.x. Trying to port over my
previous configurations has been a real headache.

Currently, I'm getting the following errors when trying to connect with:
openssl s_client -starttls smtp -connect localhost:25

Aug 21 19:08:46 localhost postfix/smtpd[26252]: connect from localhost[::1]
Aug 21 19:08:46 localhost postfix/smtpd[26252]: warning: SASL: Connect to
private/auth failed: Permission denied
Aug 21 19:08:46 localhost postfix/smtpd[26252]: fatal: no SASL
authentication mechanisms
Aug 21 19:08:47 localhost postfix/master[26226]: warning: process
/usr/libexec/postfix/smtpd pid 26252 exit status 1
Aug 21 19:08:47 localhost postfix/master[26226]: warning:
/usr/libexec/postfix/smtpd: bad command startup -- throttling

The private/auth file gets recreated if I delete it and restart dovecot.  The 
permissions are postfix:postfix.  The private dir's permissions are 
postfix:root.

If someone could help me out I'd really appreciate it.  My Dovecot and
Postfix configuration changes are below...

Thanks,

slevytam

---

POSTFIX:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
html_directory = no
inet_interfaces = localhost
inet_protocols = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = localhost
mydomain = the10thfloor.com
myhostname = mail.the10thfloor.com
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
sample_directory = /usr/share/doc/postfix-2.6.6/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/pki/tls/certs/mail_the10thfloor_com.crt
smtpd_tls_key_file = /etc/pki/tls/private/mail_the10thfloor_com-nopass.key
smtpd_tls_security_level = may
soft_bounce = no
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_gid_maps = static:502
virtual_mailbox_base = /home/vmail/
virtual_mailbox_domains = the10thfloor.com
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_uid_maps = static:502

DOVECOT:
# 2.0.beta6 (3156315704ef): /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-71.29.1.el6.x86_64 x86_64 CentOS Linux release 6.0 (Final)
auth_debug = yes
auth_verbose = yes
mail_location = maildir:~/Maildir
mbox_write_locks = fcntl
passdb {
args = username_format=%u /etc/dovecot/passwd
driver = passwd-file
}
protocols = imap lmtp
service auth {
unix_listener /var/spool/postfix/private/auth {
  group = postfix
  mode = 0600
  user = postfix
}
}
service imap-login {
inet_listener imap {
  port = 143
}
inet_listener imaps {
  port = 993
  ssl = yes
}
}
ssl_cert = 

Re: fatal: no SASL authentication mechanisms

[Patrick Ben Koetter]

* Jeff Lacki :
> >> Are these yum packages (which I tried under the names above
> >> with no luck)?  Where do I acquire them?
> 
> > For which SASL provider?
> 
> Im assuming digest-md5 is good enough, unless
> you think another mechanism is better?

plain and login are plaintext mechanisms. You can store the password crypted,
but the credentials are sent base64 encoded only. If someone reads them when
they are sent they are easily base64-decoded.

cram-md5, digest-md5 and ntlm are shared-secret mechanisms. They require
passwords to be stored in cleartext. If the database is stolen all passwords
are compromised. OTOH these mechanisms never send the password over the net.
They are safe to use during transmission.

The safest way is to use plaintext mechanisms and shield the transport with a
TLS encrypted session.

p...@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):

Re: fatal: no SASL authentication mechanisms

[Jeff Lacki]

>> Are these yum packages (which I tried under the names above
>> with no luck)?  Where do I acquire them?

> For which SASL provider?

Im assuming digest-md5 is good enough, unless
you think another mechanism is better?

Jeff

Re: fatal: no SASL authentication mechanisms

[Patrick Ben Koetter]

* Jeff Lacki :
> >> smtpd_sasl_security_options = noanonymous, noplaintext
> >> smtpd_tls_sasl_security_options = noanonymous
> >> SMTPD crashed. I really can't understand where is a problem.
> 
> > Blind guess: There are no other mechanisms installed.
> 
> > If that doesn't fix it, send debug output.
> 
> Dumb question Im sure, but how does one install other
> mechanisms like the ones listed in dovecot.conf:

That depends on the SASL provider. In Dovecot they are all there and you
create/configure a list of mechanisms that should be propagated to Postfix.

>   digest-md5 cram-md5 ntlm rpa apop gssapi otp skey gss-spnego
> 
> Im personally interested in digest-md5 and if you have
> particular feelings about the others, Id like to know
> as well.


In Cyrus SASL you install them into /usr/lib/sasl2/ and tell smtpd.conf which
ones to list with the mech_list parameter.


> Are these yum packages (which I tried under the names above
> with no luck)?  Where do I acquire them?

For which SASL provider?

p...@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):

Re: fatal: no SASL authentication mechanisms

[Jeff Lacki]

>> smtpd_sasl_security_options = noanonymous, noplaintext
>> smtpd_tls_sasl_security_options = noanonymous
>> SMTPD crashed. I really can't understand where is a problem.

> Blind guess: There are no other mechanisms installed.

> If that doesn't fix it, send debug output.

Dumb question Im sure, but how does one install other
mechanisms like the ones listed in dovecot.conf:

digest-md5 cram-md5 ntlm rpa apop gssapi otp skey gss-spnego

Im personally interested in digest-md5 and if you have
particular feelings about the others, Id like to know
as well.

Are these yum packages (which I tried under the names above
with no luck)?  Where do I acquire them?

Thanks,
Jeff

Re: fatal: no SASL authentication mechanisms

[Patrick Ben Koetter]

* Неворотин Вадим :
> I have same problem. When I try to add smtpd_sasl_security_options =
> noanonymous, noplaintext to my config smptd start to say FATAL ERROR))) Auth
> throw dovecot, works perfectly with
> 
> smtpd_tls_auth_only = yes
> 
> but then I only replace it with
> 
> smtpd_sasl_security_options = noanonymous, noplaintext
> smtpd_tls_sasl_security_options = noanonymous
> 
> SMTPD crashed. I really can't understand where is a problem.

Blind guess: There are no other mechanisms installed.

If that doesn't fix it, send debug output.

p...@rick

Re: fatal: no SASL authentication mechanisms

[Patrick Ben Koetter]

* Jeff Lacki :
> 
> Im trying to setup SASL+TLS+dovecot.  Overall Ive
> gotten things somewhat working, but have a couple questions
> since Im new to this aspect of postfix.
> 
> I get 'fatal: no SASL authentication mechanisms' in maillog
> I ran saslfinger and it showed no mechanisms,
> 
> my /usr/lib/sasl2/smtpd.conf contains:
> 
> pwcheck_method: saslauthd
> mech_list: plain login 

Forget saslfinger for Dovecot. It was made for debugging Cyrus SASL only. Also
forget /usr/lib/sasl2/smtpd.conf. It configures Cyrus SASL, but you want
Dovecot SASL.

You have smtpd_sasl_type = dovecot, which is correct.

You also have smtpd_tls_auth_only = yes, which only let's you AUTH once a TLS
connection has been established.

Turn it off, while you test.

Have you verified SMTP AUTH works without TLS?

If you get "fatal: no SASL authentication mechanisms" then Dovecot likely
doesn't export any mechanisms to Postfix. To have it do so you will have to
tweak Dovecots configuration.

p...@rick



> saslauthd is installed and running
> 
> I dont think it matters, but I have what many others
> said they were missing: cyrus-sasl-plain installed.
> 
> Am I supposed to add other 'mechanisms' and if so,
> how do I do so?  Which packages do I add etc?
> 
> Thanks!
> 
> my postconf -n:
> 
> ddress_verify_map = hash:/etc/postfix/address_verify_map
> alias_maps = hash:/etc/postfix/aliases
> allow_percent_hack = yes
> append_at_myorigin = yes
> append_dot_mydomain = yes
> broken_sasl_auth_clients = yes
> canonical_maps = hash:/etc/postfix/canonical
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> daemon_directory = /usr/libexec/postfix
> data_directory = /var/lib/postfix
> debug_peer_level = 2
> default_transport = smtp
> disable_vrfy_command = yes
> empty_address_recipient = MAILER-DAEMON
> header_checks = regexp:/etc/postfix/header_checks
> html_directory = no
> ignore_mx_lookup_error = no
> in_flow_delay = 1s
> inet_interfaces = all
> mail_owner = postfix
> mail_spool_directory = /var/spool/mail
> mailq_path = /usr/bin/mailq.postfix
> manpage_directory = /usr/share/man
> message_size_limit = 1500
> mydestination = $myhostname, localhost.$mydomain $mydomain
> myhostname = mydomain.com
> mynetworks = 127.0.0.0/8
> mynetworks_style = subnet
> myorigin = $myhostname
> newaliases_path = /usr/bin/newaliases.postfix
> notify_classes = resource,software
> parent_domain_matches_subdomains = 
> queue_directory = /var/spool/postfix
> readme_directory = /usr/share/doc/postfix-2.4.5/README_FILES
> relay_domains = $mynetworks
> sample_directory = /usr/share/doc/postfix-2.4.5/samples
> sendmail_path = /usr/sbin/sendmail.postfix
> setgid_group = postdrop
> smtp_always_send_ehlo = no
> smtp_connect_timeout = 30s
> smtp_data_done_timeout = 600s
> smtp_data_init_timeout = 120s
> smtp_data_xfer_timeout = 180s
> smtp_destination_concurrency_limit = 10
> smtp_helo_timeout = 300s
> smtp_mail_timeout = 300s
> smtp_never_send_ehlo = no
> smtp_pix_workaround_delay_time = 10s
> smtp_pix_workaround_threshold_time = 500s
> smtp_quit_timeout = 300s
> smtp_rcpt_timeout = 300s
> smtp_sasl_mechanism_filter = login
> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
> smtp_sasl_security_options = noanonymous
> smtp_skip_5xx_greeting = yes
> smtp_skip_quit_response = yes
> smtp_tls_note_starttls_offer = yes
> smtp_use_tls = yes
> smtpd_client_restrictions = permit_mynetworks,  check_client_access 
> hash:/etc/postfix/client_access
> smtpd_data_restrictions = reject_unauth_pipelining, permit
> smtpd_hard_error_limit = 6
> smtpd_helo_required = yes
> smtpd_helo_restrictions = permit_mynetworks,check_client_access 
> hash:/etc/postfix/good_clients, hash:/etc/postfix/access,   
> hash:/etc/postfix/bad_ips,  reject_unknown_helo_hostname,   
> reject_non_fqdn_hostname,   reject_unauth_destination,  
> reject_unauth_pipelining,   
> reject_invalid_hostname,reject_unknown_hostname
> smtpd_recipient_restrictions = permit_mynetworks,   
> permit_sasl_authenticated,  reject_unauth_destination
> smtpd_restriction_classes = restrictive, permissive
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_authenticated_header = yes
> smtpd_sasl_local_domain = 
> smtpd_sasl_path = private/auth
> smtpd_sasl_security_options = noanonymous, noplaintext
> smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
> smtpd_sasl_type = dovecot
> smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders
> smtpd_sender_restrictions = reject_unknown_sender_domain
> smtpd_soft_error_limit = 4
> smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
> smtpd_

Re: fatal: no SASL authentication mechanisms

[/dev/rob0]

On Thu, Feb 11, 2010 at 06:22:55PM -0800, Jeff Lacki wrote:
> > >> smtpd_tls_auth_only = yes
> > 
> > > Do you know what this parameter setting does?
> 
> After hours of digging into this, that particular message
> seems to have come up because I didnt want plaintext
> coming across in the smtp connection so I set:
> 
>   smtpd_sasl_security_options = noanonymous, noplaintext
> 
> By having noplaintext I got the msg because my
> dovecot and SASL configs weren't setup to handle
> anything but plain and login, so...
> 
> in /etc/dovecot.conf
> auth default {
>   mechanisms = plain login digest-md5
> }
> 
> in smtpd.conf:

Irrelevant; that is a Cyrus SASL file. You seem to have confused
Dovecot and Cyrus. Look only at the Dovecot section in the Postfix
SASL_README, and you will see no mention at all of saslauthd nor
Cyrus configuration files.

> The SASL doc didnt explain about setting up 
> smtpd_sasl_security_options with noplaintext (afaik) in
> what I was reading per the mechanisms so I got lost.

SASL_README presents a basic setup of Dovecot SASL. Advanced Dovecot
features are documented at http://wiki.dovecot.org/ .

> Im just posting this for the next guy who might have
> a problem.

Let's hope he doesn't waste time on Cyrus, if he's wanting to use
Dovecot. :)
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: fatal: no SASL authentication mechanisms

[Jeff Lacki]

> >> smtpd_tls_auth_only = yes
> 
> > Do you know what this parameter setting does?
> 

After hours of digging into this, that particular message
seems to have come up because I didnt want plaintext
coming across in the smtp connection so I set:

smtpd_sasl_security_options = noanonymous, noplaintext

By having noplaintext I got the msg because my
dovecot and SASL configs weren't setup to handle
anything but plain and login, so...

in /etc/dovecot.conf
auth default {
mechanisms = plain login digest-md5
}

in smtpd.conf:
pwcheck_method: saslauthd
mech_list: plain login digest-md5

Adding digest-md5 solved that error message.

The SASL doc didnt explain about setting up 
smtpd_sasl_security_options with noplaintext (afaik) in
what I was reading per the mechanisms so I got lost.

Im just posting this for the next guy who might have
a problem.

Thanks for your pointers.

Re: fatal: no SASL authentication mechanisms

[Victor Duchovni]

On Thu, Feb 11, 2010 at 03:55:52PM -0800, Jeff Lacki wrote:

> >> smtpd_tls_auth_only = yes
> 
> > Do you know what this parameter setting does?
> 
> Not exactly, Ive been reading all kinds of docs and since
> Im new to some of it, Im a little confused between
> SASL and TLS.  I've used postfix for a while but never
> dove into the encrypted aspects of things for security.
> Now Im trying to get secure.

The parameter, is documented at

http://www.postfix.org/postconf.5.html#smtpd_tls_auth_only

if you take a moment to reflect on the "yes" setting, you will understand
why tools that probe the list of available SASL algorithms may find none.

-- 
Viktor.

P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment.  If you are interested, please drop me a note.

Re: fatal: no SASL authentication mechanisms

[Wietse Venema]

Jeff Lacki:
> >> I get 'fatal: no SASL authentication mechanisms' in maillog
> 
> >> smtpd_tls_auth_only = yes
> 
> > Do you know what this parameter setting does?
> 
> Not exactly, Ive been reading all kinds of docs and since
> Im new to some of it, Im a little confused between
> SASL and TLS.  I've used postfix for a while but never
> dove into the encrypted aspects of things for security.
> Now Im trying to get secure.
> 
> I was reading http://www.postfix.org/SASL_README.html
> 
> to get SASL+TLS (hopefully) setup to allow specific
> users to relay through my server securely, but maybe
> Im completely going down the wrong path?
> 
> I appreciate the help.

Instead of random websites, you may want to take a look at the
much updated and expanded SASL_README file.

http://www.postfix.org/SASL_README.html

Wietse

Re: fatal: no SASL authentication mechanisms

[Jeff Lacki]

>> I get 'fatal: no SASL authentication mechanisms' in maillog

>> smtpd_tls_auth_only = yes

> Do you know what this parameter setting does?

Not exactly, Ive been reading all kinds of docs and since
Im new to some of it, Im a little confused between
SASL and TLS.  I've used postfix for a while but never
dove into the encrypted aspects of things for security.
Now Im trying to get secure.

I was reading http://www.postfix.org/SASL_README.html

to get SASL+TLS (hopefully) setup to allow specific
users to relay through my server securely, but maybe
Im completely going down the wrong path?

I appreciate the help.

Re: fatal: no SASL authentication mechanisms

[Victor Duchovni]

On Thu, Feb 11, 2010 at 03:13:52PM -0800, Jeff Lacki wrote:

> I get 'fatal: no SASL authentication mechanisms' in maillog

> smtpd_tls_auth_only = yes

Do you know what this parameter setting does?

-- 
Viktor.

P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment.  If you are interested, please drop me a note.

fatal: no SASL authentication mechanisms

[Jeff Lacki]

Im trying to setup SASL+TLS+dovecot.  Overall Ive
gotten things somewhat working, but have a couple questions
since Im new to this aspect of postfix.

I get 'fatal: no SASL authentication mechanisms' in maillog
I ran saslfinger and it showed no mechanisms,

my /usr/lib/sasl2/smtpd.conf contains:

pwcheck_method: saslauthd
mech_list: plain login 

saslauthd is installed and running

I dont think it matters, but I have what many others
said they were missing: cyrus-sasl-plain installed.

Am I supposed to add other 'mechanisms' and if so,
how do I do so?  Which packages do I add etc?

Thanks!

my postconf -n:

ddress_verify_map = hash:/etc/postfix/address_verify_map
alias_maps = hash:/etc/postfix/aliases
allow_percent_hack = yes
append_at_myorigin = yes
append_dot_mydomain = yes
broken_sasl_auth_clients = yes
canonical_maps = hash:/etc/postfix/canonical
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
default_transport = smtp
disable_vrfy_command = yes
empty_address_recipient = MAILER-DAEMON
header_checks = regexp:/etc/postfix/header_checks
html_directory = no
ignore_mx_lookup_error = no
in_flow_delay = 1s
inet_interfaces = all
mail_owner = postfix
mail_spool_directory = /var/spool/mail
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 1500
mydestination = $myhostname, localhost.$mydomain $mydomain
myhostname = mydomain.com
mynetworks = 127.0.0.0/8
mynetworks_style = subnet
myorigin = $myhostname
newaliases_path = /usr/bin/newaliases.postfix
notify_classes = resource,software
parent_domain_matches_subdomains = 
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.4.5/README_FILES
relay_domains = $mynetworks
sample_directory = /usr/share/doc/postfix-2.4.5/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_always_send_ehlo = no
smtp_connect_timeout = 30s
smtp_data_done_timeout = 600s
smtp_data_init_timeout = 120s
smtp_data_xfer_timeout = 180s
smtp_destination_concurrency_limit = 10
smtp_helo_timeout = 300s
smtp_mail_timeout = 300s
smtp_never_send_ehlo = no
smtp_pix_workaround_delay_time = 10s
smtp_pix_workaround_threshold_time = 500s
smtp_quit_timeout = 300s
smtp_rcpt_timeout = 300s
smtp_sasl_mechanism_filter = login
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_skip_5xx_greeting = yes
smtp_skip_quit_response = yes
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
smtpd_client_restrictions = permit_mynetworks,  check_client_access 
hash:/etc/postfix/client_access
smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_hard_error_limit = 6
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,check_client_access 
hash:/etc/postfix/good_clients, hash:/etc/postfix/access,   
hash:/etc/postfix/bad_ips,  reject_unknown_helo_hostname,   
reject_non_fqdn_hostname,   reject_unauth_destination,  
reject_unauth_pipelining,   reject_invalid_hostname,reject_unknown_hostname
smtpd_recipient_restrictions = permit_mynetworks,   
permit_sasl_authenticated,  reject_unauth_destination
smtpd_restriction_classes = restrictive, permissive
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = 
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
smtpd_sasl_type = dovecot
smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders
smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_soft_error_limit = 4
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
unverified_recipient_reject_code = 550
virtual_alias_domains = nim-phila.org
virtual_alias_maps = hash:/etc/postfix/virtual