Re: Recipient address rejected: User unknown in local recipient table
On 3/29/2019 5:04 AM, luckydog xf wrote:
Hi,
I'm new to postfix, and I use postfix + dovecot, and I add MX/A/PTR.
I use Mariadb as Dovecot passdb and Cyrus SASL Authentication.
And I configure email client (MUA) and try to send email to
another user in the same domain, it says,
"Recipient address rejected: User unknown in local recipient table"
I can read literally this user does not exist on this machine. How
can I solve this problem?
I also read docs of postfix, which is quite difficult for me since
I'm new to email field.
Postfix needs to know which domains it should handle, the valid
users, and what postfix should do with that mail.
It sounds like all your users are stored in dovecot and not unix
system users. Postfix calls this a virtual mailbox domain. Some
docs for that can be found here:
http://www.postfix.org/VIRTUAL_README.html#virtual_mailbox
Other documents can be found here:
http://www.postfix.org/documentation.html
You'll probably want something like:
mydestination = localhost (or set this empty)
virtual_mailbox_domains = {your domain name here}
virtual_mailbox_maps = {dovecot user database here}
virtual_transport = {dovecot delivery agent here}
You may also find one of the postfix books helpful, "The Book of
Postfix" by Hildebrandt and Koetter; or "Postfix: The Definitive
Guide" by Dent. Both are very old and won't cover new features, but
the basic structure of postfix hasn't changed, and they're still
useful for an overview of how things work.
-- Noel Jones
Re: domain-specific virtual_alias_maps file
Mattia Rizzolo: > Is it possible to have anything like that? Also assuming in the future > this host will have to handle a separate domain, I'd prefer to have > different files for each set of aliases, and keep it tidy. Postfix supports multiple aliases files; that is usually how mailman is hooked up with Postfix, if you use the Postfix local delivery agent. alias_maps = hash:/etc/aliases, hash:/path/to/mailman/aliases, ... There currently is no simple way to have different alias_maps settings for different domains; that is because the Postfix local delivery agent implements a domain-less flat namespace. It is possible to configure different Postfix local delivery agents for different domains, each agent having its own "-o alias_maps" setting in master.cf, but I would not consider that simple. Of course that is not a problem with virtual_alias maps; there, each alias contains the domain name that it belongs in. Wietse
Re: Postfix benchmark: bug or performance regression ?
Ralf Hildebrandt: > * Viktor Dukhovni : > > > On Mar 28, 2019, at 12:03 PM, Wietse Venema wrote: > > > > > > And thank you for your thorough investigation that helped to narrow > > > down the root cause: under high traffic conditions, LMTP connections > > > are cached but never reused, therefore those idle cached connections > > > are exhausting server resources. > > > > Yes, thanks. I was similarly impressed by the OP's detailed report. > > > > For the record, in case anyone has not read the entire thread, the issue > > is only with LMTP over unix-domain sockets. LMTP over TCP is not affected. > > Ah, excellent. I was already afraid my setup would occasionally suffer > from this effect. LMTP over TCP uses the same code paths as SMTP. Wietse
Re: Is the limitation on password text in a file for smtp_sasl_password_maps
Vladimir Lomov: > Hello, > > I faced with strange problem with my postfix configuration. I use the postfix > as SMTP client to send emails from my host. Recently I changed the password > on external email-server, updated file that stores passwords and now I see > SASL authentication failures in log. I wonder is the limitation on password > part in the file pointed by smtp_sasl_password_maps? > > This is password part of my postfix configuration: > > smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd > > where sasl_passwd has following format: > > account@MAIL.SERVER account:PASSWORD > > The only restriction on PASSWORD that email-server puts is to avoid > ' and ~ symbols, right now PASSWORD has any except these symbols, > for example it has symbols: ;:". What is the output from: postmap -q account@MAIL.SERVER | od -cb Does it show anything unexpected, or does it not show anything that you would expect to be in the output? > I read the documentation but didn't find any restrictions on > PASSWORD part. Do I missed something? When you create hash:/etc/postfix/sasl_passwd, the postmap command will - strip leading whitespace before 'account:password' - strip and trailing whitespace after 'account:password' - store text as null-terminated strings. Therefore, the postmap command will not store leading whitespace in the 'account' portion, will not store trailing whitespace in the 'password' portion, and will not store text that follows a null byte. The password lookup code splits the 'account:password' lookup result as follows: passwd = split_at(session->sasl_username, ':'); Where session->sasl_username initially contains the entire lookup result. The split_at() call consumes exactly one ':' character. Therefore, there must be no ':' in the 'account' portion of the sasl_passwd lookup result. Otherwise, split_at() does not introduce any additional syntax restrictions on sasl_passwd syntax beyond those already introduced by the postmap command. Wietse
domain-specific virtual_alias_maps file
Hi,
I'm setting up a new site that is going to handle all a mailing list
(with mailman, on its own domain lists.example.org) and a few aliases
@example.org. The host is named mail1.example.org.
I successfully did it using:
- main.cf:
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail1.example.org, localhost
relay_domains = lists.example.org
virtual_alias_maps = hash:/etc/postfix/virtual_domains
mailman_destination_recipient_limit = 1
transport_maps = hash:/etc/postfix/transport
-
- master.cf
mailman unix - n n - - pipe
flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
${nexthop} ${user}
-
- transport
lists.example.org mailman:
-
virtual_domains
mat...@example.org mat...@mapreri.org
f...@example.org blablabla@gmail
f...@example.org asdasdasd@gmail
-
Now, this all works, but there is one thing that has been nagging me.
Backstory: I also inherited a host running exim4 that handles a few
aliases, and there I have a file /etc/exim4/aliases/example.org, and in
exim4.conf there this snippet:
- exim4.conf
domain_aliases:
driver = redirect
allow_fail
allow_defer
domains = dsearch;/etc/exim4/aliases
data = ${lookup{$local_part}wildlsearch{/etc/exim4/aliases/$domain}}
-
Then the alias file is just
- /etc/exim4/aliases/example.org
root: mat...@mapreri.org
info: root
blabla: a@b.c, d@e.f
-
...and the like, without having @example.org at each alias line. It's
really the same syntax of the system's /etc/aliases, but it applies only
the single virtual domain (or "virtual alias" in postfix terms, I guess).
Is it possible to have anything like that? Also assuming in the future
this host will have to handle a separate domain, I'd prefer to have
different files for each set of aliases, and keep it tidy.
Thank you in advance for any suggestion you can give me!
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Postfix benchmark: bug or performance regression ?
* Viktor Dukhovni : > > On Mar 28, 2019, at 12:03 PM, Wietse Venema wrote: > > > > And thank you for your thorough investigation that helped to narrow > > down the root cause: under high traffic conditions, LMTP connections > > are cached but never reused, therefore those idle cached connections > > are exhausting server resources. > > Yes, thanks. I was similarly impressed by the OP's detailed report. > > For the record, in case anyone has not read the entire thread, the issue > is only with LMTP over unix-domain sockets. LMTP over TCP is not affected. Ah, excellent. I was already afraid my setup would occasionally suffer from this effect. -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG, 80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Is the limitation on password text in a file for smtp_sasl_password_maps
Hello, I faced with strange problem with my postfix configuration. I use the postfix as SMTP client to send emails from my host. Recently I changed the password on external email-server, updated file that stores passwords and now I see SASL authentication failures in log. I wonder is the limitation on password part in the file pointed by smtp_sasl_password_maps? This is password part of my postfix configuration: smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd where sasl_passwd has following format: account@MAIL.SERVER account:PASSWORD The only restriction on PASSWORD that email-server puts is to avoid ' and ~ symbols, right now PASSWORD has any except these symbols, for example it has symbols: ;:". I read the documentation but didn't find any restrictions on PASSWORD part. Do I missed something? --- WBR, Vladimir Lomov
Re: PATCH: Postfix benchmark: bug or performance regression ?
Juliana Rodrigueiro: > On Friday, 29 March 2019 00:49:34 CET Wietse Venema wrote: > > > > > This is a patch for LMTP connection reuse over UNIX-domain sockets. > > > > Bugfix (introduced: Postfix 3.0): LMTP connections over > > UNIX-domain sockets were cached but not reused, due to a > > cache lookup key mismatch. Therefore, idle cached connections > > could exhaust LMTP server resources, resulting in two-second > > pauses between email deliveries. This problem was investigated > > by Juliana Rodrigueiro. File: smtp/smtp_connect.c. > > > > These diffs are identical except that in Postfix 3.4 some macros > > were renamed to better match their purpose. > > > > Tested with Postfix 3.5. Please give it a try. > > > > wietse > > There is a small problem in the 3.1-3.3.diff though. I believe the variable > "dest" should actually be "path". Oh, right. > I quickly tested with this modifications in postfix 3.3.2 and everything > worked. > > Thank you a lot for the patch! Thanks for testing. Wietse
Recipient address rejected: User unknown in local recipient table
Hi, I'm new to postfix, and I use postfix + dovecot, and I add MX/A/PTR. I use Mariadb as Dovecot passdb and Cyrus SASL Authentication. And I configure email client (MUA) and try to send email to another user in the same domain, it says, "Recipient address rejected: User unknown in local recipient table" I can read literally this user does not exist on this machine. How can I solve this problem? I also read docs of postfix, which is quite difficult for me since I'm new to email field. # postconf -n broken_sasl_auth_clients = yes command_directory = /usr/sbin compatibility_level = 2 daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 default_privs = nobody home_mailbox = Maildir/ html_directory = no inet_interfaces = all inet_protocols = ipv4 mail_owner = postfix mail_spool_directory = /var/spool/mail mailbox_transport = lmtp:unix:/usr/var/run/dovecot/lmtp local_recipient_maps = mailq_path = /usr/bin/mailq manpage_directory = /usr/local/man meta_directory = /etc/postfix mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain mydomain = ad.pthl.hk myhostname = mail.ad.pthl.hk mynetworks = 172.16.0.0/12, 127.0.0.0/8, 172.16.81.0/24 myorigin = $mydomain newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = no relay_domains = $mydestination sample_directory = /etc/postfix sendmail_path = /usr/sbin/sendmail setgid_group = postdrop shlib_directory = /usr/lib/postfix smtp_tls_note_starttls_offer = yes smtp_tls_security_level = may smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,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/ssl/certs/dovecot.pem smtpd_tls_key_file = /etc/ssl/certs/dovecot.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may unknown_local_recipient_reject_code = 550 What do I have to setup? I only have a single domain Thanks,
Re: PATCH: Postfix benchmark: bug or performance regression ?
On Friday, 29 March 2019 00:49:34 CET Wietse Venema wrote: > > This is a patch for LMTP connection reuse over UNIX-domain sockets. > > Bugfix (introduced: Postfix 3.0): LMTP connections over > UNIX-domain sockets were cached but not reused, due to a > cache lookup key mismatch. Therefore, idle cached connections > could exhaust LMTP server resources, resulting in two-second > pauses between email deliveries. This problem was investigated > by Juliana Rodrigueiro. File: smtp/smtp_connect.c. > > These diffs are identical except that in Postfix 3.4 some macros > were renamed to better match their purpose. > > Tested with Postfix 3.5. Please give it a try. > > wietse There is a small problem in the 3.1-3.3.diff though. I believe the variable "dest" should actually be "path". I quickly tested with this modifications in postfix 3.3.2 and everything worked. Thank you a lot for the patch! Julie.
