R: R: R: Strange behaviour of my multi-instance server
Dear Mr. Dukhovni, you're right, I'm not a great expert of Postfix but I'm here to learn! In fact, you're last answer is the solution of my problem: Sure looks like you don't understand that each instance of an smtp(8) transport needs all the relevant settings specified. There's no inheritance between smtp and slow for example. I just updated my master.cf, and ALL IS FINALLY CORRECT: -- MASTER.CF --- xxx.xxx.xxx.79:smtp inet n - n - 10 smtpd smtp unix - - n - - smtp -o syslog_name=postfix-smtp79 -o smtp_helo_name=mx4.domain.it -o myhostname= mx4.domain.it -o smtp_bind_address= xxx.xxx.xxx.79 veryslow unix - - n - - smtp -o smtp_fallback_relay= -o syslog_name=postfix- smtp79 -o smtp_helo_name= mx4.domain.it -o myhostname= mx4.domain.it -o smtp_bind_address= xxx.xxx.xxx.79 slow unix - - n - - smtp -o smtp_fallback_relay= -o syslog_name=postfix- smtp79 -o smtp_helo_name= mx4.domain.it -o myhostname= mx4.domain.it -o smtp_bind_address= xxx.xxx.xxx.79 -- END MASTER.CF --- I thought that was ineritance between smtp and other transports settings (slow, veryslow, etc.) :-( THANK YOU A LOT! However I've another question. Here below is a snippet from master.cf of another instance where I use a Perl script for randomizing the smtp client to be used for outbound email: --- MASTER.CF- 127.0.0.1:21025 inet n n n - 0 spawn user=nobody argv=/etc/postfix/random-block1.pl smtp2 unix - - n - - smtp -o syslog_name=postfix-smtp2 -o smtp_helo_name=mx2.dominio1.it -o smtp_bind_address=xxx.xxx.xxx.111 smtp3 unix - - n - - smtp -o syslog_name=postfix-smtp3 -o smtp_helo_name=mx3. dominio1.it -o smtp_bind_address= xxx.xxx.xxx.112 smtp1 unix - - n - - smtp -o syslog_name=postfix-smtp5 -o smtp_helo_name=mx5. dominio1.it -o smtp_bind_address= xxx.xxx.xxx.113 veryslow unix - - n - - smtp -o smtp_fallback_relay= slow unix - - n - - smtp -o smtp_fallback_relay= --- END MASTER.CF- Here is the transport file used in my configuration: TRANSPORT - testdom.it slow: testdom.com veryslow: trydom.it slow: trydom.com slow: END TRANSPORT - Well: with the configuration files above, how can I update veryslow and slow transports for each IPs? What smtp_bind_address I have to set for slow/veryslow? Uhmm... I hope to have been clear. Thanks for your help! -Francesco --- Questa e-mail è stata controllata per individuare virus con Avast antivirus. http://www.avast.com
Re: R: R: Strange behaviour of my multi-instance server
On Tue, Mar 24, 2015 at 01:51:12PM +0100, MegaBrutal wrote: I don't understand Postfix internals so deeply, but I see another possible problem. Please correct me if I'm wrong! Basically, you want to run separate instances of Postfix in separate processes, right? These instances (if not configured carefully) probably put their queue files in the same directory (/var/spool/postfix by Debian default). Isn't it possible that there is a race condition between multiple instances, and an e-mail queued by one instance actually gets delivered by another instance (thus another IP)? No. And these are not instances of Postfix sharing a queue directory. -- Viktor.
Re: File count mismatch in spool directories
On 3/23/2015 9:40 AM, Viktor Dukhovni wrote: The extra files are not a problem. Don't count files in defer. If you're using long queue-ids, and your clock is not prone to moving backwards, you can automate removal of defer files that are older than some reasonable multiple of the maximal_queue_lifetime. With a queue lifetime of 5 days, removing long queue-id defer files older than 30 days is likely safe. Otherwise, you have to stop Postfix and run postsuper -s. The machine runs ntpd continuously, so I *think* the clock won't go backwards. The maximal_queue_lifetime setting is not in my postconf -n output, so the default of 5 days is likely. I do not have long queue ids turned on. Is it still safe to wait a month and then wipe out any files in the spool older than 30 days? Thanks, Shawn
Re: R: R: Strange behaviour of my multi-instance server
I don't understand Postfix internals so deeply, but I see another possible problem. Please correct me if I'm wrong! Basically, you want to run separate instances of Postfix in separate processes, right? These instances (if not configured carefully) probably put their queue files in the same directory (/var/spool/postfix by Debian default). Isn't it possible that there is a race condition between multiple instances, and an e-mail queued by one instance actually gets delivered by another instance (thus another IP)? If you've taken care of this, or it is not a problem for Postfix, or in case I said something very stupid, I'm sorry. 2015-03-24 11:29 GMT+01:00 i...@itrezero.it: Dear Mr. Dukhovni, you're right, I'm not a great expert of Postfix but I'm here to learn! In fact, you're last answer is the solution of my problem: Sure looks like you don't understand that each instance of an smtp(8) transport needs all the relevant settings specified. There's no inheritance between smtp and slow for example. I just updated my master.cf, and ALL IS FINALLY CORRECT: -- MASTER.CF --- xxx.xxx.xxx.79:smtp inet n - n - 10 smtpd smtp unix - - n - - smtp -o syslog_name=postfix-smtp79 -o smtp_helo_name=mx4.domain.it -o myhostname= mx4.domain.it -o smtp_bind_address= xxx.xxx.xxx.79 veryslow unix - - n - - smtp -o smtp_fallback_relay= -o syslog_name=postfix- smtp79 -o smtp_helo_name= mx4.domain.it -o myhostname= mx4.domain.it -o smtp_bind_address= xxx.xxx.xxx.79 slow unix - - n - - smtp -o smtp_fallback_relay= -o syslog_name=postfix- smtp79 -o smtp_helo_name= mx4.domain.it -o myhostname= mx4.domain.it -o smtp_bind_address= xxx.xxx.xxx.79 -- END MASTER.CF --- I thought that was ineritance between smtp and other transports settings (slow, veryslow, etc.) :-( THANK YOU A LOT! However I've another question. Here below is a snippet from master.cf of another instance where I use a Perl script for randomizing the smtp client to be used for outbound email: --- MASTER.CF- 127.0.0.1:21025 inet n n n - 0 spawn user=nobody argv=/etc/postfix/random-block1.pl smtp2 unix - - n - - smtp -o syslog_name=postfix-smtp2 -o smtp_helo_name=mx2.dominio1.it -o smtp_bind_address=xxx.xxx.xxx.111 smtp3 unix - - n - - smtp -o syslog_name=postfix-smtp3 -o smtp_helo_name=mx3. dominio1.it -o smtp_bind_address= xxx.xxx.xxx.112 smtp1 unix - - n - - smtp -o syslog_name=postfix-smtp5 -o smtp_helo_name=mx5. dominio1.it -o smtp_bind_address= xxx.xxx.xxx.113 veryslow unix - - n - - smtp -o smtp_fallback_relay= slow unix - - n - - smtp -o smtp_fallback_relay= --- END MASTER.CF- Here is the transport file used in my configuration: TRANSPORT - testdom.it slow: testdom.com veryslow: trydom.it slow: trydom.com slow: END TRANSPORT - Well: with the configuration files above, how can I update veryslow and slow transports for each IPs? What smtp_bind_address I have to set for slow/veryslow? Uhmm... I hope to have been clear. Thanks for your help! -Francesco --- Questa e-mail è stata controllata per individuare virus con Avast antivirus. http://www.avast.com
Re: R: R: R: Strange behaviour of my multi-instance server
On Tue, Mar 24, 2015 at 11:29:42AM +0100, i...@itrezero.it wrote: --- MASTER.CF- 127.0.0.1:21025 inet n n n - 0 spawn user=nobody argv=/etc/postfix/random-block1.pl smtp2 unix - - n - - smtp -o syslog_name=postfix-smtp2 -o smtp_helo_name=mx2.dominio1.it -o smtp_bind_address=xxx.xxx.xxx.111 smtp3 unix - - n - - smtp -o syslog_name=postfix-smtp3 -o smtp_helo_name=mx3. dominio1.it -o smtp_bind_address= xxx.xxx.xxx.112 smtp1 unix - - n - - smtp -o syslog_name=postfix-smtp5 -o smtp_helo_name=mx5. dominio1.it -o smtp_bind_address= xxx.xxx.xxx.113 veryslow unix - - n - - smtp -o smtp_fallback_relay= slow unix - - n - - smtp -o smtp_fallback_relay= --- END MASTER.CF- To distribute load among multiple IPs also for slow/veryslow, you'll need to have multiple instances of slow and very slow, and appropriate ways to randomly distribute load among them. At which point it is clear that you're much better off with separate Postfix instances per address, each with its own smtp/slow/veryslow transport. And just inject the mail into those at random. The second solution ensures that for any given message the address used is stable over time, and so encounters shorter greylisting delays. Your current configuration is a bad idea, so don't make it worse by also splitting the slow/veryslow transports. Happy snow-shoeing... -- Viktor.
Re: Goodbye IBM, Hello Google
On Tue, 24 Mar 2015 16:00:01 -0400 (EDT), Wietse Venema stated: After 18 years, including the best of my career, I decided that it was time to move on. I'll be working on security at Google NY. Please, there is no reason to say negative things about my old employer (or my new one!). Needless to say, I will continue to support Postfix. Wietse Best of luck to you Wietse. In your spare time, perhaps you can fix their insane IMAP implementation. -- Jerry
Re: File count mismatch in spool directories
On 3/24/2015 12:55 AM, Shawn Heisey wrote: On 3/23/2015 9:40 AM, Viktor Dukhovni wrote: The extra files are not a problem. Don't count files in defer. If you're using long queue-ids, and your clock is not prone to moving backwards, you can automate removal of defer files that are older than some reasonable multiple of the maximal_queue_lifetime. With a queue lifetime of 5 days, removing long queue-id defer files older than 30 days is likely safe. Otherwise, you have to stop Postfix and run postsuper -s. The machine runs ntpd continuously, so I *think* the clock won't go backwards. The maximal_queue_lifetime setting is not in my postconf -n output, so the default of 5 days is likely. You can issue the command: postconf maximal_queue_lifetime to display the value postfix is using. I do not have long queue ids turned on. Is it still safe to wait a month There are possible race conditions with normal short queue ids. Either enable long queue ids or stop postfix before removing old defer files. I suggest enabling long queue ids. The only reason to not enable long queue ids is if you're using some ancient log analysis tool that can't parse the longer IDs. http://www.postfix.org/postconf.5.html#enable_long_queue_ids and then wipe out any files in the spool older than 30 days? Only files in the defer directory, not any files in the spool. -- Noel Jones
Re: virtual domains and hosting
On 3/23/2015 4:25 PM, Rafał Michalak wrote: Hello, I have this situation in one server I have many domains, normally postfix delivers email direct locally but when user change email hosting, system still sends emails to old server (don't checks mx and delivers locally). I read something about postfix two instances, but when I set it i have this same error message Recipient address rejected: User unknown in virtual mailbox table; (user create new account on new server but doesn't in old server) What I must change in Postfix to check mx and delivers directly without locally prioritization. Thanks for help Domains listed in virtual_mailbox_domains are delivered locally. If a domain moves, the domain must be removed from your virtual_mailbox_domains. Postfix can't do this automatically. I suppose you could write a script to do an MX lookup on each domain and send you an alert if the MX points somewhere else. -- Noel Jones
Re: Goodbye IBM, Hello Google
On Mar 24, 2015, at 14:00, Wietse Venema wie...@porcupine.org wrote: After 18 years, including the best of my career, I decided that it was time to move on. I'll be working on security at Google NY. Congratulations. I have a good friend at Google NY who works on the back end for maps, IIRC. -- There's a race of men that don't fit in, A race that can't stay still So they break the hearts of kith and kin, And they roam the world at will.
Re: Goodbye IBM, Hello Google
Congratulations... On Wed, Mar 25, 2015 at 5:41 AM, @lbutlr krem...@kreme.com wrote: On Mar 24, 2015, at 14:00, Wietse Venema wie...@porcupine.org wrote: After 18 years, including the best of my career, I decided that it was time to move on. I'll be working on security at Google NY. Congratulations. I have a good friend at Google NY who works on the back end for maps, IIRC. -- There's a race of men that don't fit in, A race that can't stay still So they break the hearts of kith and kin, And they roam the world at will. -- Thanks Regards, Kranti Kiran Patnaik +91-924-633-52-62 Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
R: R: R: R: Strange behaviour of my multi-instance server
So, you suggest to: 1) use many singleIP-instances with specific smtp/slow/veryslow/etc. transports (all bound on the same IP) 2) not use a randomizer script in the master.cf BUT randomizing the outbound address through web application (that is a PHP script) Is it correct? But here I have a further question (never really answered in my searches on Internet): how many instances can I set up on the same machine without deteriorating perfomances? I know that this answer is linked to the resources of the server, so suppose that it's a dual-core with 4 GB RAM. Thanks again -Francesco -Messaggio originale- Da: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] Per conto di Viktor Dukhovni Inviato: martedì 24 marzo 2015 14:30 A: postfix-users@postfix.org Oggetto: Re: R: R: R: Strange behaviour of my multi-instance server On Tue, Mar 24, 2015 at 11:29:42AM +0100, i...@itrezero.it wrote: --- MASTER.CF- 127.0.0.1:21025 inet n n n - 0 spawn user=nobody argv=/etc/postfix/random-block1.pl smtp2 unix - - n - - smtp -o syslog_name=postfix-smtp2 -o smtp_helo_name=mx2.dominio1.it -o smtp_bind_address=xxx.xxx.xxx.111 smtp3 unix - - n - - smtp -o syslog_name=postfix-smtp3 -o smtp_helo_name=mx3. dominio1.it -o smtp_bind_address= xxx.xxx.xxx.112 smtp1 unix - - n - - smtp -o syslog_name=postfix-smtp5 -o smtp_helo_name=mx5. dominio1.it -o smtp_bind_address= xxx.xxx.xxx.113 veryslow unix - - n - - smtp -o smtp_fallback_relay= slow unix - - n - - smtp -o smtp_fallback_relay= --- END MASTER.CF- To distribute load among multiple IPs also for slow/veryslow, you'll need to have multiple instances of slow and very slow, and appropriate ways to randomly distribute load among them. At which point it is clear that you're much better off with separate Postfix instances per address, each with its own smtp/slow/veryslow transport. And just inject the mail into those at random. The second solution ensures that for any given message the address used is stable over time, and so encounters shorter greylisting delays. Your current configuration is a bad idea, so don't make it worse by also splitting the slow/veryslow transports. Happy snow-shoeing... -- Viktor. --- Questa e-mail è stata controllata per individuare virus con Avast antivirus. http://www.avast.com
Re: Goodbye IBM, Hello Google
Congratulations to both you and Google! On Tue, Mar 24, 2015 at 4:00 PM, Wietse Venema wie...@porcupine.org wrote: After 18 years, including the best of my career, I decided that it was time to move on. I'll be working on security at Google NY. Please, there is no reason to say negative things about my old employer (or my new one!). Needless to say, I will continue to support Postfix. Wietse
Re: Goodbye IBM, Hello Google
El 24/03/2015 a las 20:00, Wietse Venema escribió: After 18 years, including the best of my career, I decided that it was time to move on. I'll be working on security at Google NY. Please, there is no reason to say negative things about my old employer (or my new one!). Needless to say, I will continue to support Postfix. Wietse Another Google's nice signing. Congrats to both :-)
Re: Goodbye IBM, Hello Google
Congratulations! 24 марта 2015 г. 23:01 пользователь Wietse Venema wie...@porcupine.org написал: After 18 years, including the best of my career, I decided that it was time to move on. I'll be working on security at Google NY. Please, there is no reason to say negative things about my old employer (or my new one!). Needless to say, I will continue to support Postfix. Wietse
Re: Goodbye IBM, Hello Google
Congratulations Wietse ! Good luck on this new venture ! Em ter, 24 de mar de 2015 às 17:00, Wietse Venema wie...@porcupine.org escreveu: After 18 years, including the best of my career, I decided that it was time to move on. I'll be working on security at Google NY. Please, there is no reason to say negative things about my old employer (or my new one!). Needless to say, I will continue to support Postfix. Wietse
Re: Goodbye IBM, Hello Google
As an engineering manager of mine used to say, Another opportunity to excel. Thanks for all the help in the past and all the help to come. Best of luck in the new job. Mike After 18 years, including the best of my career, I decided that it was time to move on. I'll be working on security at Google NY. Please, there is no reason to say negative things about my old employer (or my new one!). Needless to say, I will continue to support Postfix. Wietse -- Mike McGinn KD2CNU Be happy that brainfarts don't smell. No electrons were harmed in sending this message, some were inconvenienced. ** Registered Linux User 377849
Re: Goodbye IBM, Hello Google
wie...@porcupine.org (Wietse Venema) wrote: After 18 years, including the best of my career, I decided that it was time to move on. I'll be working on security at Google NY. Please, there is no reason to say negative things about my old employer (or my new one!). Needless to say, I will continue to support Postfix. Wietse Congrats, and enjoy. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
RE: Goodbye IBM, Hello Google
Congratulations. Vince Wang -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Miles Fidelman Sent: Tuesday, March 24, 2015 1:21 PM To: Postfix users Subject: Re: Goodbye IBM, Hello Google wie...@porcupine.org (Wietse Venema) wrote: After 18 years, including the best of my career, I decided that it was time to move on. I'll be working on security at Google NY. Please, there is no reason to say negative things about my old employer (or my new one!). Needless to say, I will continue to support Postfix. Wietse Congrats, and enjoy. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Goodbye IBM, Hello Google
After 18 years, including the best of my career, I decided that it was time to move on. I'll be working on security at Google NY. Please, there is no reason to say negative things about my old employer (or my new one!). Needless to say, I will continue to support Postfix. Wietse
RE: Goodbye IBM, Hello Google
Congratulations and best of luck in your new job. -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix- us...@postfix.org] On Behalf Of Wietse Venema Sent: Tuesday, March 24, 2015 4:00 PM To: Postfix users Subject: Goodbye IBM, Hello Google After 18 years, including the best of my career, I decided that it was time to move on. I'll be working on security at Google NY. Please, there is no reason to say negative things about my old employer (or my new one!). Needless to say, I will continue to support Postfix. Wietse Since 1982, Starpoint Solutions has been a trusted source of human capital and solutions. We are committed to our clients, employees, environment, community and social concerns. We foster an inclusive culture based on trust, respect, honesty and solid performance. Learn more about Starpoint and our social responsibility at http://www.starpoint.com/social_responsibility This email message from Starpoint Solutions LLC is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Opinions, conclusions and other information in this message that do not relate to the official business of Starpoint Solutions shall be understood as neither given nor endorsed by it.
Re: Goodbye IBM, Hello Google
Congratulation! All the best to you and your future roles :) On Tue, Mar 24, 2015 at 4:00 PM, Wietse Venema wie...@porcupine.org wrote: After 18 years, including the best of my career, I decided that it was time to move on. I'll be working on security at Google NY. Please, there is no reason to say negative things about my old employer (or my new one!). Needless to say, I will continue to support Postfix. Wietse
Re: Goodbye IBM, Hello Google
On Mar 24, 2015, at 2:00 PM, Wietse Venema wie...@porcupine.org wrote: After 18 years, including the best of my career, I decided that it was time to move on. I'll be working on security at Google NY. Good for Google. They've got a competent programmer. Needless to say, I will continue to support Postfix. Very glad to hear that! -- Glenn English
Re: virtual domains and hosting
OK you have right
root@node1:/usr/local/bin# postfinger
postfinger - postfix configuration on Tue Mar 24 09:09:14 CET 2015
version: 1.30
--System Parameters--
mail_version = 3.0.0
hostname = node1
uname = Linux node1 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
--Packaging information--
--main.cf non-default parameters--
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
compatibility_level = 2
content_filter = vscan:[127.0.0.1]:10024
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id sleep 5
dovecot_destination_recipient_limit = 1
home_mailbox = Maildir/
multi_instance_directories = /etc/postfix-out
multi_instance_enable = yes
multi_instance_wrapper = ${command_directory}/postmulti -p --
relayhost = [mx-out]:9025
smtpd_recipient_restrictions = permit_sasl_authenticated,
reject_unknown_reverse_client_hostname, reject_unauth_pipelining,
reject_invalid_hostname, reject_non_fqdn_recipient,
reject_non_fqdn_sender, reject_unknown_recipient_domain,
reject_unknown_sender_domain, reject_non_fqdn_hostname,
reject_invalid_helo_hostname, reject_unauth_destination,
reject_unknown_helo_hostname, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_mynetworks
reject_unknown_sender_domain warn_if_reject reject_unverified_sender
smtp_host_lookup = dns, native
smtputf8_enable = no
unverified_sender_reject_code = 550
unverified_sender_reject_reason = Address_xxx_verification failed
virtual_alias_maps = mysql:/etc/postfix/mysql_alias-maps.cf
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/mail
virtual_mailbox_domains = mysql:/etc/postfix/mysql_mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql_mailbox-maps.cf
virtual_minimum_uid = 201
virtual_transport = lmtp:unix:private/dovecot-lmtp
virtual_uid_maps = static:5000
--master.cf--
127.0.0.1:10025 inet n - n - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
-o
receive_override_options=no_unknown_recipient_checks,no_header_body_checks
127.0.0.1:submission inetn - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
aaa.bbb.ccc.dd:smtp inet n - - - - smtpd
-o smtpd_tls_cert_file=/etc/ssl/certs/mail_.crt
-o smtpd_tls_key_file=/etc/ssl/private/mail.xxx.key
-o smtpd_tls_CAfile=/etc/ssl/certs/mail.xxx.ca.crt
aaa.bbb.ccc.dd:submission inet n - - - - smtpd
-o smtpd_tls_cert_file=/etc/ssl/certs/mail_.crt
-o smtpd_tls_key_file=/etc/ssl/private/mail..key
-o smtpd_tls_CAfile=/etc/ssl/certs/mail..ca.crt
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
pickupunix n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr unix n - n 300 1 qmgr
tlsmgrunix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounceunix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verifyunix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
showq unix n - n - - showq
error unix - - n - - error
retry unix - - n - - error
discard unix - - n - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scacheunix - - n - 1 scache
maildrop unix - n n - - pipe
flags=Ru user=postfix argv=/usr/local/bin/maildrop -d ${recipient}
dovecot unix - n n
