Re: automatic email account configuration, postfix pipelining restriction

[Brendan Kearney]

On 04/21/2018 07:59 PM, David Mehler wrote:

Hello Viktor,

Bingo! That did it. In the .xml file I changed ssl to encryption tls
and it well got further than it did. I had some issues with smtpd*
restrictions specifically helo restrictions, I commented them out. So
outlook autodiscover is working, thunderbird autoconfig still is not.

Going to start another thread about my smtpd* restrictions, but any
other suggestions on thunderbird appreciated.

Thanks for helping with outlook.
Dave.


On 4/21/18, Viktor Dukhovni  wrote:



On Apr 21, 2018, at 2:06 PM, David Mehler  wrote:

Thanks. I'm sorry I should probably have more completely clarified
that. Different client entirely, the previous message I was attempting
autoconfig with Thunderbird and getting those errors.

This time I'm trying outlook 2010 with autodiscover and getting the
errors in my last message. I thought to keep it under the same thread.

For completeness and because I probably confused everyone, here's an
outlook 2010 attempted connection and my current main.cf and master.cf
files.

Apr 21 13:52:54 hostname postfix/submission/smtpd[74637]: connect from
Connecting-Host-And-IP
Apr 21 13:52:54 hostname postfix/submission/smtpd[74637]: lost
connection after UNKNOWN from Connecting-Host-And-IP
Apr 21 13:52:54 hostname postfix/submission/smtpd[74637]: disconnect
from Connecting-Host-And-IP unknown=0/1 commands=0/1

You've probably configured Outlook to do (implicit) SSL on port 587,
rather than STARTTLS.  You should either direct its connections to
port 465 with "wrapper mode TLS", or configure it to do STARTTLS on
587.

--
Viktor.



look into

https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration

and

https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat

note, using MX records in DNS supersedes the config file, so choose your 
poison wisely.


in your web server docroot, create a dir called mail, in mail, edit 
config-v1.1.xml.  mine is cited below for convenience:





  
bpk2.com
bpk2.com
bpk2

  imap.bpk2.com
  143
  STARTTLS
  GSSAPI
  %EMAILLOCALPART%


  submission.bpk2.com
  587
  
  plain
  GSSAPI
  %EMAILLOCALPART%

http://www.bpk2.com/imap.html;>
  IMAP General Settings

http://www.bpk2.com/smtp.html;>
  SMTP General Settings

  
  
https://www.bpk2.com/roundcube/; />
https://www.bpk2.com/roundcube/;>
  %EMAILLOCALPART%

  

dnsblog lifetime

[Doug Hardie]

I understood from the dnsblog man page that each dnsblog process only lives for 
a "limited amount of time".  I noticed this because I have over 50 dnsblog 
processes running on a fairly light duty postfix server.  Some of them are over 
a week old.  At first I thought they must have been orphaned, but looking 
through maillog, I find entries in the last few minutes from the oldest and the 
newest.  I didn't check all of them, but it appears they are all in use.  
Looking at the source for postfix-3.3-20180114 (on web), it appears dnsblog 
checks one IP address and then exits.  I believe I can limit the number of 
dnsblog processes in master.cf (currently set to 0), but I am not sure that is 
a good idea.  How long are these processes supposed to live?

-- Doug

smtpd restrictions

[David Mehler]

Hello,

I'm running Postfix 3.3. I'm thinking I've got an issue with my smtpd*
restrictions, either doing double work or not ordered right, or just
not optimized. Can someone take a look and see if anything stands out
as being off?

Thanks.
Dave.

master.cf (service excerpt):
submission inet n   -   n   -   -   smtpd
 -o syslog_name=postfix/submission
  -o smtpd_tls_dh1024_param_file=/etc/ssl/dhparam.pem
 -o smtpd_tls_security_level=encrypt
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_sasl_type=dovecot
 -o smtpd_sasl_path=private/auth
 -o smtpd_sasl_security_options=noanonymous
 -o 
smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject
 -o smtpd_sender_login_maps=mysql:/usr/local/etc/postfix/db/sender-login-maps.cf
 -o tls_preempt_cipherlist=yes

main.cf (smtpd* restrictions):
strict_rfc821_envelopes = yes
disable_vrfy_command = yes
smtpd_reject_unlisted_sender = yes
show_user_unknown_table_name = no
unknown_address_reject_code  = 554
unknown_hostname_reject_code = 554
unknown_client_reject_code   = 554

# Conditions in which Postfix works as a relay. (for mail user clients)
smtpd_relay_restrictions =
 reject_non_fqdn_recipient
 reject_unknown_recipient_domain
 permit_mynetworks
 reject_unauth_destination

smtpd_recipient_restrictions =
  permit_mynetworks
 permit_sasl_authenticated
  reject_unauth_destination
check_helo_access hash:/usr/local/etc/postfix/helo_access,
,check_helo_access pcre:/usr/local/etc/postfix/helo_checks
,check_sender_mx_access cidr:/usr/local/etc/postfix/bogus_mx
 check_sender_access hash:/usr/local/etc/postfix/safe_addresses
 check_sender_access hash:/usr/local/etc/postfix/auto-whtlst
 check_client_access cidr:/usr/local/etc/postfix/spamfarms
 check_client_access cidr:/usr/local/etc/postfix/sinokorea.cidr
 check_recipient_access mysql:/usr/local/etc/postfix/db/recipient-access.cf
 permit_dnswl_client list.dnswl.org=127.0.[2..14].[1..3]
check_reverse_client_hostname_access
pcre:/usr/local/etc/postfix/fqrdns.pcre
 reject_unknown_reverse_client_hostname
  reject_non_fqdn_sender
# The below commented lines were commented to make outlook work
 #reject_non_fqdn_helo_hostname
 reject_invalid_helo_hostname
 #reject_unknown_helo_hostname
 reject_unlisted_recipient
 reject_rhsbl_client dbl.spamhaus.org
 reject_rhsbl_sender dbl.spamhaus.org
 reject_rhsbl_helo dbl.spamhaus.org
  check_policy_service unix:private/spf-policy
 check_policy_service unix:private/dovecot-quota

# Restrictions for all sending foreign servers ("SMTP clients")
smtpd_client_restrictions =
 permit_mynetworks
 check_client_access hash:/usr/local/etc/postfix/without_ptr
 reject_unknown_client_hostname

smtpd_helo_required = yes
smtpd_helo_restrictions =
 permit_mynetworks
 reject_invalid_helo_hostname
# The below lines were commented to make outlook work
 #reject_non_fqdn_helo_hostname
 #reject_unknown_helo_hostname

# Block clients, which start sending too early
smtpd_data_restrictions = reject_unauth_pipelining

# Restrictions for MUAs
#mua_relay_restrictions =
reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_mynetworks,permit_sasl_authenticated,reject
#mua_sender_restrictions =
permit_mynetworks,reject_non_fqdn_sender,reject_sender_login_mismatch,permit_sasl_authenticated,reject
#mua_client_restrictions = permit_mynetworks,permit_sasl_authenticated,reject

Re: automatic email account configuration, postfix pipelining restriction

[David Mehler]

Hello Viktor,

Bingo! That did it. In the .xml file I changed ssl to encryption tls
and it well got further than it did. I had some issues with smtpd*
restrictions specifically helo restrictions, I commented them out. So
outlook autodiscover is working, thunderbird autoconfig still is not.

Going to start another thread about my smtpd* restrictions, but any
other suggestions on thunderbird appreciated.

Thanks for helping with outlook.
Dave.


On 4/21/18, Viktor Dukhovni  wrote:
>
>
>> On Apr 21, 2018, at 2:06 PM, David Mehler  wrote:
>>
>> Thanks. I'm sorry I should probably have more completely clarified
>> that. Different client entirely, the previous message I was attempting
>> autoconfig with Thunderbird and getting those errors.
>>
>> This time I'm trying outlook 2010 with autodiscover and getting the
>> errors in my last message. I thought to keep it under the same thread.
>>
>> For completeness and because I probably confused everyone, here's an
>> outlook 2010 attempted connection and my current main.cf and master.cf
>> files.
>>
>> Apr 21 13:52:54 hostname postfix/submission/smtpd[74637]: connect from
>> Connecting-Host-And-IP
>> Apr 21 13:52:54 hostname postfix/submission/smtpd[74637]: lost
>> connection after UNKNOWN from Connecting-Host-And-IP
>> Apr 21 13:52:54 hostname postfix/submission/smtpd[74637]: disconnect
>> from Connecting-Host-And-IP unknown=0/1 commands=0/1
>
> You've probably configured Outlook to do (implicit) SSL on port 587,
> rather than STARTTLS.  You should either direct its connections to
> port 465 with "wrapper mode TLS", or configure it to do STARTTLS on
> 587.
>
> --
>   Viktor.
>
>

Re: automatic email account configuration, postfix pipelining restriction

[Viktor Dukhovni]

> On Apr 21, 2018, at 2:06 PM, David Mehler  wrote:
> 
> Thanks. I'm sorry I should probably have more completely clarified
> that. Different client entirely, the previous message I was attempting
> autoconfig with Thunderbird and getting those errors.
> 
> This time I'm trying outlook 2010 with autodiscover and getting the
> errors in my last message. I thought to keep it under the same thread.
> 
> For completeness and because I probably confused everyone, here's an
> outlook 2010 attempted connection and my current main.cf and master.cf
> files.
> 
> Apr 21 13:52:54 hostname postfix/submission/smtpd[74637]: connect from
> Connecting-Host-And-IP
> Apr 21 13:52:54 hostname postfix/submission/smtpd[74637]: lost
> connection after UNKNOWN from Connecting-Host-And-IP
> Apr 21 13:52:54 hostname postfix/submission/smtpd[74637]: disconnect
> from Connecting-Host-And-IP unknown=0/1 commands=0/1

You've probably configured Outlook to do (implicit) SSL on port 587,
rather than STARTTLS.  You should either direct its connections to
port 465 with "wrapper mode TLS", or configure it to do STARTTLS on
587.

-- 
Viktor.

Re: automatic email account configuration, postfix pipelining restriction

[David Mehler]

Hello,

Thanks. I'm sorry I should probably have more completely clarified
that. Different client entirely, the previous message I was attempting
autoconfig with Thunderbird and getting those errors.

This time I'm trying outlook 2010 with autodiscover and getting the
errors in my last message. I thought to keep it under the same thread.

For completeness and because I probably confused everyone, here's an
outlook 2010 attempted connection and my current main.cf and master.cf
files.

Apr 21 13:52:54 hostname postfix/submission/smtpd[74637]: connect from
Connecting-Host-And-IP
Apr 21 13:52:54 hostname postfix/submission/smtpd[74637]: lost
connection after UNKNOWN from Connecting-Host-And-IP
Apr 21 13:52:54 hostname postfix/submission/smtpd[74637]: disconnect
from Connecting-Host-And-IP unknown=0/1 commands=0/1

#cat master.cf
smtp  inet  n   -   n   -   -   smtpd
#smtp  inet  n   -   n   -   1   postscreen
 #-o smtpd_sasl_auth_enable=no
#smtpd pass  -   -   n   -   -   smtpd
dnsblog   unix  -   -   n   -   0   dnsblog
tlsproxy  unix  -   -   n   -   0   tlsproxy
# Submission port 587 for client connection / sending mails from
authenticated users
submission inet n   -   n   -   -   smtpd -v
 -o syslog_name=postfix/submission
 # Encrypt by default
  -o smtpd_tls_dh1024_param_file=/etc/ssl/dhparam.pem
 -o smtpd_tls_security_level=encrypt
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_sasl_type=dovecot
 -o smtpd_sasl_path=private/auth
 -o smtpd_sasl_security_options=noanonymous
 -o 
smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject
 -o tls_preempt_cipherlist=yes
#smtps inet  n   -   n   -   -   smtpd
  #-o syslog_name=postfix/smtps
  #-o smtpd_tls_wrappermode=yes
  #-o smtpd_sasl_auth_enable=yes
  #-o smtpd_reject_unlisted_recipient=no
  #-o 
smtpd_recipient_restrictions=permit_sasl_authenticated,permit_mynetworks,reject
  #-o tls_preempt_cipherlist=yes
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=
#  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#628   inet  n   -   n   -   -   qmqpd
pickupunix  n   -   n   60  1   pickup
cleanup   unix  n   -   n   -   0   cleanup
qmgr  unix  n   -   n   300 1   qmgr
#qmgr unix  n   -   n   300 1   oqmgr
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
#   -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
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

# for SPF support
spf-policy unix -   n   n   -   0   spawn
  user=vmail argv=/usr/local/bin/perl
/usr/local/libexec/postfix-policyd-spf-perl

dfilt unix-   n   n   -   -   pipe
flags=Rq user=filter argv=/usr/local/etc/postfix/disclaimer -f
${sender} -r ${recipient}

# scan service for clamsmtpd
scan unix -   -   n   -   16   smtp
   -o smtp_data_done_timeout=1200
   -o smtp_send_xforward_command=yes
   -o disable_dns_lookups=yes

127.0.0.1:10026 inet n   -   n   -   16   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_style=host
   -o smtpd_authorized_xforward_hosts=127.0.0.0/8

#cat main.cf

Re: automatic email account configuration, postfix pipelining restriction

[Wietse Venema]

David Mehler:
> Hello,
> 
> I am still trying to get this email sending with autodiscover working.
> I've temporarily put Thunderbird aside as it looks like it has a long
> standing compatibility issue with sending commands to early, and have
> switched to outlook 2010. With it I am getting the following which I
> do not know what unknown is.
> 
> Apr 21 04:22:38 hostname postfix/submission/smtpd[44179]: connect from
> Connecting-Host-and-IP
> Apr 21 04:22:39 hostname postfix/submission/smtpd[44179]: lost
> connection after UNKNOWN from Connection-hostname-ip

Please do not remove crucial evidence. 

I suppose that you still have

Apr 20 14:37:00 hostname postfix/submission/smtpd[92360]:
improper command pipelining after EHLO from
Connecting-Machine-Hostname-And-IP: QUIT\r\n.

If you don't have this, what did you do to change the client's
behavior?

I suppose that you also have:

disconnect from hostname[address] ehlo=1...

What is the complete set of logfile records?

Wietse

Re: Mails stuck in queue until inflow stops

[Stephen Satchell]

On 04/21/2018 04:38 AM, Ram wrote:

There is no IO load running everything in /dev/shm


You can verify your claim by running vmstat(8), such as in:

  vmstat 20 20

(20 times for 20 seconds each time)

You might be surprised how much file system activity there is, even when 
you put all of PostFix's files in /dev/shm.  For example, are all of 
PostFix's binaries in /dev/shm?  How about the modules loaded by PostFix?

Re: Mails stuck in queue until inflow stops

[Ron Wheeler]

On 21/04/2018 8:07 AM, Ram wrote:



On 04/21/2018 05:32 PM, Ron Wheeler wrote:

On 21/04/2018 7:38 AM, Ram wrote:



On 04/20/2018 07:39 PM, Wietse Venema wrote:

Ram:


On 04/20/2018 07:14 PM, Wietse Venema wrote:

Ram:
I have a very busy postfix server that acts as a relay. It gets 
mails
from an application and then forwards the mails to the delivery 
servers

on local LAN

The application can send mails at rate of? upto 600 mails per 
second
Postfix has been configured to accept mails all that quickly, 
but the
delivery is very poor until inflow stops. Only around 20-50 
mails per s
Once the app completes the inflow, then the mails are cleared at 
a rate

of 1000 mails per second

Why ?

Is there a contention on the queue manager when the inflow is 
too quick ?

No, there is contention for the file system.

If you disabled in_flow_delay, turn it back on, please. This allows
the queue manager to push back, though it works only for clients
that make few parallel connections.

Otherwise, you need a faster disk. SSDs have become quite 
affordable,
even the 'enterprise' ones that have some extra capacitors to 
prevent

data corruption after power failure.

I am using spool dir on /dev/shm

in flow delay .. slows down smtp connections which the application 
can

not handle
That is why I have disabled

If you can't use the Postfix safety mechanism, then I can't help you.


I know , And in_fllow_delay  works for almost all cases where I use 
postfix. Excepting when 1 sec delay per process becomes too much


If I have a high end machine , will running multiple postfix 
instances on the same machine help
That way If I change the app to deliver to multiple instances 
simultaneously.

There is no IO load running everything in /dev/shm





If you look at a system monitor output (top on Linux is enough), is 
Postfix using 100% of the CPU? Is there a significant amount of 
process time in wait queues? Is there lots of spare physical memory?


Probably a silly question but are you sure that the sending 
application or network is not the bottleneck?


If you configure Postfix to throw away the e-mails immediately in 
receipt does the inflow meet your expectations.

I thought so too.
I tried using postfix-sink and the mails are sent at max speed. So the 
network is not a problem




https://netcore.in/20-years-journey/?utm_source=email-disclaimer_medium=email_campaign=netcore-turns-20 





Does the analysis of which postfix tasks are eating the CPU give any hints?

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Mails stuck in queue until inflow stops

[Ron Wheeler]

On 21/04/2018 7:38 AM, Ram wrote:



On 04/20/2018 07:39 PM, Wietse Venema wrote:

Ram:


On 04/20/2018 07:14 PM, Wietse Venema wrote:

Ram:

I have a very busy postfix server that acts as a relay. It gets mails
from an application and then forwards the mails to the delivery 
servers

on local LAN

The application can send mails at rate of? upto 600 mails per second
Postfix has been configured to accept mails all that quickly, but the
delivery is very poor until inflow stops. Only around 20-50 mails 
per s
Once the app completes the inflow, then the mails are cleared at a 
rate

of 1000 mails per second

Why ?

Is there a contention on the queue manager when the inflow is too 
quick ?

No, there is contention for the file system.

If you disabled in_flow_delay, turn it back on, please. This allows
the queue manager to push back, though it works only for clients
that make few parallel connections.

Otherwise, you need a faster disk. SSDs have become quite affordable,
even the 'enterprise' ones that have some extra capacitors to prevent
data corruption after power failure.

I am using spool dir on /dev/shm

in flow delay .. slows down smtp connections which the application can
not handle
That is why I have disabled

If you can't use the Postfix safety mechanism, then I can't help you.


I know , And in_fllow_delay  works for almost all cases where I use 
postfix. Excepting when 1 sec delay per process becomes too much


If I have a high end machine , will running multiple postfix instances 
on the same machine help
That way If I change the app to deliver to multiple instances 
simultaneously.

There is no IO load running everything in /dev/shm




https://netcore.in/20-years-journey/?utm_source=email-disclaimer_medium=email_campaign=netcore-turns-20 





I hope that you have no spam or virus checking on the inflow.


--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Mails stuck in queue until inflow stops

[Ram]

On 04/20/2018 07:39 PM, Wietse Venema wrote:

Ram:


On 04/20/2018 07:14 PM, Wietse Venema wrote:

Ram:

I have a very busy postfix server that acts as a relay. It gets mails
from an application and then forwards the mails to the delivery servers
on local LAN

The application can send mails at rate of? upto 600 mails per second
Postfix has been configured to accept mails all that quickly, but the
delivery is very poor until inflow stops. Only around 20-50 mails per s
Once the app completes the inflow, then the mails are cleared at a rate
of 1000 mails per second

Why ?

Is there a contention on the queue manager when the inflow is too quick ?

No, there is contention for the file system.

If you disabled in_flow_delay, turn it back on, please. This allows
the queue manager to push back, though it works only for clients
that make few parallel connections.

Otherwise, you need a faster disk. SSDs have become quite affordable,
even the 'enterprise' ones that have some extra capacitors to prevent
data corruption after power failure.

I am using spool dir on /dev/shm

in flow delay .. slows down smtp connections which the application can
not handle
That is why I have disabled

If you can't use the Postfix safety mechanism, then I can't help you.


I know , And in_fllow_delay  works for almost all cases where I use 
postfix. Excepting when 1 sec delay per process becomes too much


If I have a high end machine , will running multiple postfix instances 
on the same machine help
That way If I change the app to deliver to multiple instances 
simultaneously.

There is no IO load running everything in /dev/shm




https://netcore.in/20-years-journey/?utm_source=email-disclaimer_medium=email_campaign=netcore-turns-20

Re: automatic email account configuration, postfix pipelining restriction

[David Mehler]

Hello,

I am still trying to get this email sending with autodiscover working.
I've temporarily put Thunderbird aside as it looks like it has a long
standing compatibility issue with sending commands to early, and have
switched to outlook 2010. With it I am getting the following which I
do not know what unknown is.

Apr 21 04:22:38 hostname postfix/submission/smtpd[44179]: connect from
Connecting-Host-and-IP
Apr 21 04:22:39 hostname postfix/submission/smtpd[44179]: lost
connection after UNKNOWN from Connection-hostname-ip

I've tried adjusting broken_sasl_auth_clients no by default, set it to
yes, didn't change anything.

My current smtpd_restrictions:
main.cf:
# Conditions in which Postfix works as a relay. (for mail user clients)
smtpd_relay_restrictions =
 reject_non_fqdn_recipient
 reject_unknown_recipient_domain
 permit_mynetworks
 reject_unauth_destination

smtpd_recipient_restrictions =
  permit_mynetworks
 permit_sasl_authenticated
  reject_unauth_destination
check_helo_access hash:/usr/local/etc/postfix/helo_access,
,check_helo_access pcre:/usr/local/etc/postfix/helo_checks
,check_sender_mx_access cidr:/usr/local/etc/postfix/bogus_mx
 check_sender_access hash:/usr/local/etc/postfix/safe_addresses
 check_sender_access hash:/usr/local/etc/postfix/auto-whtlst
 check_client_access cidr:/usr/local/etc/postfix/spamfarms
 check_client_access cidr:/usr/local/etc/postfix/sinokorea.cidr
 check_recipient_access mysql:/usr/local/etc/postfix/db/recipient-access.cf
 permit_dnswl_client list.dnswl.org=127.0.[2..14].[1..3]
check_reverse_client_hostname_access
pcre:/usr/local/etc/postfix/fqrdns.pcre
 reject_unknown_reverse_client_hostname
  reject_non_fqdn_sender
 #reject_non_fqdn_helo_hostname
 #reject_invalid_helo_hostname
 #reject_unknown_helo_hostname
 reject_unlisted_recipient
 reject_rhsbl_client dbl.spamhaus.org
 reject_rhsbl_sender dbl.spamhaus.org
 reject_rhsbl_helo dbl.spamhaus.org
  check_policy_service unix:private/spf-policy
# Postfix Quota status service
 #check_policy_service inet:127.0.0.1:12345
 check_policy_service unix:private/dovecot-quota

# Restrictions for all sending foreign servers ("SMTP clients")
smtpd_client_restrictions =
 permit_mynetworks
 #check_client_access hash:/usr/local/etc/postfix/without_ptr
 #reject_unknown_client_hostname

smtpd_helo_required = yes
smtpd_helo_restrictions =
 #permit_mynetworks
 #reject_invalid_helo_hostname
 #reject_non_fqdn_helo_hostname
 #reject_unknown_helo_hostname

# Block clients, which start sending too early
#smtpd_data_restrictions = reject_unauth_pipelining

# Restrictions for MUAs
#mua_relay_restrictions =
reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_mynetworks,permit_sasl_authenticated,reject
#mua_sender_restrictions =
permit_mynetworks,reject_non_fqdn_sender,reject_sender_login_mismatch,permit_sasl_authenticated,reject
#mua_client_restrictions = permit_mynetworks,permit_sasl_authenticated,reject

and in master.cf:
submission inet n   -   n   -   -   smtpd
 -o syslog_name=postfix/submission
 # for opportunistic smtpd
  #-o smtpd_tls_security_level=may
 # Encrypt by default
  -o smtpd_tls_dh1024_param_file=/etc/ssl/dhparam.pem
 -o smtpd_tls_security_level=encrypt
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_sasl_type=dovecot
 -o smtpd_sasl_path=private/auth
 -o smtpd_sasl_security_options=noanonymous
 -o 
smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject
 #-o 
smtpd_sender_login_maps=mysql:/usr/local/etc/postfix/db/sender-login-maps.cf
 -o tls_preempt_cipherlist=yes
 #-o cleanup_service_name=submission-header-cleanup

Are these restrictions right in main.cf and master.cf?
Thanks.
Dave.


On 4/20/18, Wietse Venema  wrote:
> David Mehler:
>> Hi,
>>
>> It's Thunderbird 52.7. Is there a workaround to make this work?
>
> Yes, do nothing. In particular, do not use the Postfix
> reject_unauth_pipelining feature, because that would trigger
> a REJECT response.
>
>   Wietse
>
>> On 4/20/18, Viktor Dukhovni  wrote:
>> >
>> >
>> >> On Apr 20, 2018, at 4:52 PM, David Mehler 
>> >> wrote:
>> >>
>> >> I'm atempting to configure email autoconfig and autodiscover services
>> >> for Mozilla and Microsoft clients. I'm using Postfix 3.3. At first I
>> >> thought I was dealing with either an Apache or Dovecot issue, now I'm
>> >> thinking it's an error with my Postfix configuration.
>> >>
>> >> Whenever I atempt a connection I'm getting this in my postfix error
>> >> log
>> >> file:
>> >>
>> >> Apr 20 14:37:00 hostname postfix/submission/smtpd[92360]: improper
>> >> command pipelining after EHLO from Connecting-Machine-Hostname-And-IP:
>> >> QUIT\r\n
>> >
>> > This client does not implement SMTP correctly.  There's nothing wrong
>> > with the Postfix configuration.  The client MUST wait for the EHLO
>> > response *before* sending QUIT.
>> >
>> > --