part 2 of: SSL not working after unwanted server migration

[Marco Fioretti]

hello all,
this is the same server, same situation for which I asked for help
yesterday. Right now, after trying to test and follow up the advice
received, this is the status:

IMAPS: not working yet because of SSL "no shared cipher". Details
here: https://dovecot.org/pipermail/dovecot/2018-December/113862.html

POSTFIX: with the current configuration (see postconf -n output below)
it seems I can:

* receive email from all the mailing lists/newsletters I am subscribed to

* connect with mutt from my home computer, and send email through this
server to any other MTA I could use for testing, with two
"exceptions":

   gmail still refuses connection, see below what I got from the last
test a few minutes ago

  one server does accepts and deliver my messages, but flags them as
spam (no idea why, all I see is a "X-Spam-Flag: YES" header...

NOTIFICATION BY GMAIL:

: host
gmail-smtp-in.l.google.com[2a00:1450:400c:c0c::1b] said: 550-5.7.1
[] Our system has detected that this message does
550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and
550-5.7.1 authentication. Please review 550-5.7.1
https://support.google.com/mail/?p=IPv6AuthError for more information 550
5.7.1 . t6si9122052wrw.74 - gsmtp (in reply to end of DATA command)

Fact is, "" is the ipv6 address of the server for which I
*did* add a reverse entry some hours ago (and I had done the same for
the ipv4 dns record yesterday). In other words, I don't know what else
I could / should do at this point on the DNS side.

Here is the output of postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
disable_vrfy_command = yes
html_directory = /usr/share/doc/postfix-2.4.3-documentation/html
inet_interfaces = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost
mydomain = $myhostname
myhostname = a.mx.MYDOMAIN
mynetworks = 127.0.0.0/8, my.home.ip.address
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = inet:localhost:8891
procmail_destination_recipient_limit = 1
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme
relay_domains =
sample_directory = /etc/postfix
sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter =
smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_type = cyrus
smtp_sender_dependent_authentication = yes
smtp_tls_security_level = may
smtpd_helo_required = yes
smtpd_helo_restrictions =
smtpd_milters = inet:localhost:8891
smtpd_recipient_restrictions = reject_invalid_hostname,
reject_non_fqdn_hostname, reject_non_fqdn_sender,
reject_non_fqdn_recipient, reject_unknown_sender_domain,
reject_unknown_recipient_domain, permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
check_helo_access hash:/etc/postfix/reject_own_helo,
check_policy_service unix:postgrey/socket
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = /var/spool/postfix/private/auth
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/archive/MYDOMAIN/fullchain1.pem
smtpd_tls_key_file = /etc/letsencrypt/archive/MYDOMAIN/privkey1.pem
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
strict_rfc821_envelopes = yes
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/mail/mymail_storage
virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map
virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map
virtual_transport = procmail
virtual_uid_maps = static:5000
postconf: warning: /etc/postfix/main.cf: unused parameter:
smtp_tls_auth_only=yes

Re: part 2 of: SSL not working after unwanted server migration

[Benny Pedersen]

Marco Fioretti skrev den 2018-12-11 11:35:


IMAPS: not working yet because of SSL "no shared cipher". Details
here: https://dovecot.org/pipermail/dovecot/2018-December/113862.html


current SSL dovecot settings in conf.d/10-ssl.conf

is missing in dovecot -n

ask a centos maintainer for dovecot to solve that, check dovecot config 
files in /etc/dovecot/


make sure thay match what is intended from the maintainer before you 
edit it


does dovecot.conf have last line !include. ?

do you have stale old config files ?

sorry cant help more

Re: Treat only one address of a domain as local

[Matus UHLAR - fantomas]

On 11.12.18 00:28, Jonas Meurer wrote:

I want a postfix mailserver to be responsible for one particular email
address from a domain. Is this possible? The idea is the following:

* mx.example.org is the official MX for example.org and has a transport
map that forwards mail for 'b...@example.org' to another mailserver
submx.example.org.

* submx.example.org uses mx.example.org as relay server. every non-local
mail shall be forwarded to the relay for further delivery. only
'b...@example.org' is treated as local mail (i.e. delivered locally). All
other addresses for 'example.org' shall be treated as foreign addresses
(and forwarded to the relay).

Do you have an idea how to configure submx.example.org in a way to treat
'example.org' as a non-local domain except for the one particular
address 'b...@example.org'?


I believe aliasing b...@example.org in virtual_alias_maps to another user
will do what you want for all mail passing your server

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Eagles may soar, but weasels don't get sucked into jet engines. 

Re: part 2 of: SSL not working after unwanted server migration

[Robert Chalmers]

Hi again.

The following settings are from my server. They may not necessarily work with 
yours.

# Smtpd means mails you receive from outside, smtp covers mails you send to 
other servers.


The notification from Google is telling you that your Reverse DNS does not 
point to your server. Are you on a Dynamic IP, or VPS network?
> 550-5.7.1 not meet IPv6 sending guidelines regarding PTR

Have you tried setting the preferred inet to ipV4.?

inet_protocols = ipv6, ipv4
inet_interfaces=all
smtp_address_preference = ipv6

Gmail is being very picky about this stuff. You may also need to set up your 
authenticated email with Google. See the address shown in your returned email.



You also have an unused parameter  smtp_tls_auth_only  This apparently doesn’t 
exist in postfix’s set of options.
> postconf: warning: /etc/postfix/main.cf: unused parameter:
> smtp_tls_auth_only=yes

Which I think may be referring to the second line. It should be 
smtpd_tls_auth_only.

Ciphers:
1. No shared cipher. Did you fix the error in your list of  ciphers mentioned 
earlier. I doubt you actually need such a big list anyway.


smtpd_tls_ciphers = medium
smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL

smtp_tls_mandatory_ciphers = high



Robert



> On 11 Dec 2018, at 10:35, Marco Fioretti  wrote:
> 
> hello all,
> this is the same server, same situation for which I asked for help
> yesterday. Right now, after trying to test and follow up the advice
> received, this is the status:
> 
> IMAPS: not working yet because of SSL "no shared cipher". Details
> here: https://dovecot.org/pipermail/dovecot/2018-December/113862.html
> 
> POSTFIX: with the current configuration (see postconf -n output below)
> it seems I can:
> 
> * receive email from all the mailing lists/newsletters I am subscribed to
> 
> * connect with mutt from my home computer, and send email through this
> server to any other MTA I could use for testing, with two
> "exceptions":
> 
>   gmail still refuses connection, see below what I got from the last
> test a few minutes ago
> 
>  one server does accepts and deliver my messages, but flags them as
> spam (no idea why, all I see is a "X-Spam-Flag: YES" header...
> 
> NOTIFICATION BY GMAIL:
> 
> : host
>gmail-smtp-in.l.google.com[2a00:1450:400c:c0c::1b] said: 550-5.7.1
>[] Our system has detected that this message does
>550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and
>550-5.7.1 authentication. Please review 550-5.7.1
>https://support.google.com/mail/?p=IPv6AuthError for more information 550
>5.7.1 . t6si9122052wrw.74 - gsmtp (in reply to end of DATA command)
> 
> Fact is, "" is the ipv6 address of the server for which I
> *did* add a reverse entry some hours ago (and I had done the same for
> the ipv4 dns record yesterday). In other words, I don't know what else
> I could / should do at this point on the DNS side.
> 
> Here is the output of postconf -n:
> 
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> daemon_directory = /usr/libexec/postfix
> debug_peer_level = 2
> debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
> xxgdb $daemon_directory/$process_name $process_id & sleep 5
> disable_vrfy_command = yes
> html_directory = /usr/share/doc/postfix-2.4.3-documentation/html
> inet_interfaces = all
> mail_owner = postfix
> mailq_path = /usr/bin/mailq.postfix
> manpage_directory = /usr/share/man
> mydestination = $myhostname, localhost
> mydomain = $myhostname
> myhostname = a.mx.MYDOMAIN
> mynetworks = 127.0.0.0/8, my.home.ip.address
> myorigin = $mydomain
> newaliases_path = /usr/bin/newaliases.postfix
> non_smtpd_milters = inet:localhost:8891
> procmail_destination_recipient_limit = 1
> queue_directory = /var/spool/postfix
> readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme
> relay_domains =
> sample_directory = /etc/postfix
> sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps
> sendmail_path = /usr/sbin/sendmail.postfix
> setgid_group = postdrop
> smtp_sasl_auth_enable = yes
> smtp_sasl_mechanism_filter =
> smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd
> smtp_sasl_security_options = noanonymous
> smtp_sasl_tls_security_options = noanonymous
> smtp_sasl_type = cyrus
> smtp_sender_dependent_authentication = yes
> smtp_tls_security_level = may
> smtpd_helo_required = yes
> smtpd_helo_restrictions =
> smtpd_milters = inet:localhost:8891
> smtpd_recipient_restrictions = reject_invalid_hostname,
> reject_non_fqdn_hostname, reject_non_fqdn_sender,
> reject_non_fqdn_recipient, reject_unknown_sender_domain,
> reject_unknown_recipient_domain, permit_mynetworks,
> permit_sasl_authenticated, reject_unauth_destination,
> check_helo_access hash:/etc/postfix/reject_own_helo,
> check_policy_service unix:postgrey/socket
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_path = /var/spool/postfix/private/

Re: part 2 of: SSL not working after unwanted server migration

[Marco Fioretti]

that problem with Dovecot is solved. It was caused by missing (not
sure why/how) the "include conf.d/*" line in dovecot.conf, so the ssl
configuration simply was not loaded. Now with dovecot,
if anybody is interested, I have this other question about how to
configure permissions properly between dovecot and postfix:

https://dovecot.org/pipermail/dovecot/2018-December/113868.html

with postfix proper, instead, the only or main problem right now seems
to be the reverse DNS
configuration, as I reported in my previous email
Il giorno mar 11 dic 2018 alle ore 12:03 Benny Pedersen  ha 
scritto:
>
> Marco Fioretti skrev den 2018-12-11 11:35:
>
> > IMAPS: not working yet because of SSL "no shared cipher". Details
> > here: https://dovecot.org/pipermail/dovecot/2018-December/113862.html
>
> current SSL dovecot settings in conf.d/10-ssl.conf
>
> is missing in dovecot -n
>
> ask a centos maintainer for dovecot to solve that, check dovecot config
> files in /etc/dovecot/
>
> make sure thay match what is intended from the maintainer before you
> edit it
>
> does dovecot.conf have last line !include. ?
>
> do you have stale old config files ?
>
> sorry cant help more

Re: part 2 of: SSL not working after unwanted server migration

[Robert Chalmers]

oh, and run “postfix check” as the superuser.

That will show up any obvious errors.



> On 11 Dec 2018, at 10:35, Marco Fioretti  wrote:
> 
> hello all,
> this is the same server, same situation for which I asked for help
> yesterday. Right now, after trying to test and follow up the advice
> received, this is the status:
> 
> IMAPS: not working yet because of SSL "no shared cipher". Details
> here: https://dovecot.org/pipermail/dovecot/2018-December/113862.html
> 
> POSTFIX: with the current configuration (see postconf -n output below)
> it seems I can:
> 
> * receive email from all the mailing lists/newsletters I am subscribed to
> 
> * connect with mutt from my home computer, and send email through this
> server to any other MTA I could use for testing, with two
> "exceptions":
> 
>   gmail still refuses connection, see below what I got from the last
> test a few minutes ago
> 
>  one server does accepts and deliver my messages, but flags them as
> spam (no idea why, all I see is a "X-Spam-Flag: YES" header...
> 
> NOTIFICATION BY GMAIL:
> 
> : host
>gmail-smtp-in.l.google.com[2a00:1450:400c:c0c::1b] said: 550-5.7.1
>[] Our system has detected that this message does
>550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and
>550-5.7.1 authentication. Please review 550-5.7.1
>https://support.google.com/mail/?p=IPv6AuthError for more information 550
>5.7.1 . t6si9122052wrw.74 - gsmtp (in reply to end of DATA command)
> 
> Fact is, "" is the ipv6 address of the server for which I
> *did* add a reverse entry some hours ago (and I had done the same for
> the ipv4 dns record yesterday). In other words, I don't know what else
> I could / should do at this point on the DNS side.
> 
> Here is the output of postconf -n:
> 
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> daemon_directory = /usr/libexec/postfix
> debug_peer_level = 2
> debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
> xxgdb $daemon_directory/$process_name $process_id & sleep 5
> disable_vrfy_command = yes
> html_directory = /usr/share/doc/postfix-2.4.3-documentation/html
> inet_interfaces = all
> mail_owner = postfix
> mailq_path = /usr/bin/mailq.postfix
> manpage_directory = /usr/share/man
> mydestination = $myhostname, localhost
> mydomain = $myhostname
> myhostname = a.mx.MYDOMAIN
> mynetworks = 127.0.0.0/8, my.home.ip.address
> myorigin = $mydomain
> newaliases_path = /usr/bin/newaliases.postfix
> non_smtpd_milters = inet:localhost:8891
> procmail_destination_recipient_limit = 1
> queue_directory = /var/spool/postfix
> readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme
> relay_domains =
> sample_directory = /etc/postfix
> sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps
> sendmail_path = /usr/sbin/sendmail.postfix
> setgid_group = postdrop
> smtp_sasl_auth_enable = yes
> smtp_sasl_mechanism_filter =
> smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd
> smtp_sasl_security_options = noanonymous
> smtp_sasl_tls_security_options = noanonymous
> smtp_sasl_type = cyrus
> smtp_sender_dependent_authentication = yes
> smtp_tls_security_level = may
> smtpd_helo_required = yes
> smtpd_helo_restrictions =
> smtpd_milters = inet:localhost:8891
> smtpd_recipient_restrictions = reject_invalid_hostname,
> reject_non_fqdn_hostname, reject_non_fqdn_sender,
> reject_non_fqdn_recipient, reject_unknown_sender_domain,
> reject_unknown_recipient_domain, permit_mynetworks,
> permit_sasl_authenticated, reject_unauth_destination,
> check_helo_access hash:/etc/postfix/reject_own_helo,
> check_policy_service unix:postgrey/socket
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_path = /var/spool/postfix/private/auth
> smtpd_sasl_type = dovecot
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/letsencrypt/archive/MYDOMAIN/fullchain1.pem
> smtpd_tls_key_file = /etc/letsencrypt/archive/MYDOMAIN/privkey1.pem
> smtpd_tls_loglevel = 1
> smtpd_tls_security_level = may
> strict_rfc821_envelopes = yes
> unknown_address_reject_code = 554
> unknown_client_reject_code = 554
> unknown_hostname_reject_code = 554
> unknown_local_recipient_reject_code = 550
> virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map
> virtual_gid_maps = static:5000
> virtual_mailbox_base = /var/mail/mymail_storage
> virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map
> virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map
> virtual_transport = procmail
> virtual_uid_maps = static:5000
> postconf: warning: /etc/postfix/main.cf: unused parameter:
> smtp_tls_auth_only=yes

Robert Chalmers
https://robert-chalmers.uk
aut...@robert-chalmers.uk
@R_A_Chalmers

Re: part 2 of: SSL not working after unwanted server migration

[Wietse Venema]

Marco Fioretti:
> : host
> gmail-smtp-in.l.google.com[2a00:1450:400c:c0c::1b] said: 550-5.7.1
> [] Our system has detected that this message does
> 550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and
> 550-5.7.1 authentication. Please review 550-5.7.1
> https://support.google.com/mail/?p=IPv6AuthError for more information 550
> 5.7.1 . t6si9122052wrw.74 - gsmtp (in reply to end of DATA command)
> 
> Fact is, "" is the ipv6 address of the server for which I
> *did* add a reverse entry some hours ago (and I had done the same for
> the ipv4 dns record yesterday). In other words, I don't know what else
> I could / should do at this point on the DNS side.

Hours may not be enough to propagate the change to all DNS servers.

What do 'dig' or 'host' have to say about that PTR record? For my
primary server, it looks like this:

$ host 2604:8d00:189::2 
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.8.1.0.0.0.d.8.4.0.6.2.ip6.arpa domain 
name pointer spike.porcupine.org.
$ dig +short ptr 
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.8.1.0.0.0.d.8.4.0.6.2.ip6.arpa
spike.porcupine.org.

I also have configured my server not to use IPv6 with gmail. Years
ago they did not distinguish between DNS lookup timeout or 'record
does not exist'. That configuration is still in effect so I don't
know if the problem has been fixed.

Wietse

Re: part 2 of: SSL not working after unwanted server migration

[Marco Fioretti]

Hello, all.

I have added or edited as suggested in main.cf all the settings that
Robert mentions in his reply below. Right now,  "postfix check" only
returns ~10 warnings all equal to " /etc/postfix/master.cf: unused
parameter: flags=D"

everything is working OK on the imap/dovecot side (except some minor
issues I will deal with later). The only problem that remains is the
one with gmail, but I have something new to report.

Using example.com as domain name placeholder, the DNS record may be OK
now (please confirm):

a) it includes a text entry for
"example.com:google-site-verification..." as Google
b) there is a reverse IPv6 entry, and it has propagated. About 20 minutes ago,
 "host  did start to return exactly "example.com"

BUT:

I only realized now that the rejection email I get when I try to send
email as ma...@example.com to my gmail address says:

Reporting-MTA: dns; a.mx.example.com

this in turn led me to realize that the value of myhostname in main.cf
is "a.mx.example.com", NOT just "example.com" as it says in the DNS
records (*). To test myself, I changed myhostname to example.com, but
after restart I get messages to me bounced because ma...@example.com
is "User unknown in local recipient table". So, is just "example.com"
the right value for myhostname, and if yes, how to fix the user
unknown error?
Here is the current output of postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
disable_vrfy_command = yes
html_directory = /usr/share/doc/postfix-2.4.3-documentation/html
inet_interfaces = all
inet_protocols = ipv6, ipv4
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost
mydomain = $myhostname
myhostname = example.com
mynetworks = 127.0.0.0/8, my.ip.home.address
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = inet:localhost:8891
procmail_destination_recipient_limit = 1
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme
relay_domains =
sample_directory = /etc/postfix
sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_address_preference = ipv6
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter =
smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_type = cyrus
smtp_sender_dependent_authentication = yes
smtp_tls_mandatory_ciphers = high
smtp_tls_security_level = may
smtpd_helo_required = yes
smtpd_helo_restrictions =
smtpd_milters = inet:localhost:8891
smtpd_recipient_restrictions = reject_invalid_hostname,
reject_non_fqdn_hostname, reject_non_fqdn_sender,
reject_non_fqdn_recipient, reject_unknown_sender_domain,
reject_unknown_recipient_domain, permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
check_helo_access hash:/etc/postfix/reject_own_helo,
check_policy_service unix:postgrey/socket
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = /var/spool/postfix/private/auth
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/archive/example.com/fullchain1.pem
smtpd_tls_ciphers = medium
smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL
smtpd_tls_key_file = /etc/letsencrypt/archive/example.com/privkey1.pem
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
smtpd_use_tls = yes
strict_rfc821_envelopes = yes
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/mail/mymail_storage
virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map
virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map
virtual_transport = procmail
virtual_uid_maps = static:1001
postconf: warning: /etc/postfix/master.cf: unused parameter: flags=D

THANKS,
Marco

(*) please don't ask why this mismatch... it is one more of the things
that I had no time to check myself because I had to migrate without
advice...)
Il giorno mar 11 dic 2018 alle ore 13:16 Robert Chalmers
 ha scritto:
>
>
>
>
> Hi again.
>
> The following settings are from my server. They may not necessarily work with 
> yours.
>
> # Smtpd means mails you receive from outside, smtp covers mails you send to 
> other servers.
>
>
> The notification from Google is telling you that your Reverse DNS does not 
> point to your server. Are you on a Dynamic IP, or VPS network?
> > 550-5.7.1 not meet IPv6 sending guidelines regarding PTR
>
> Have you tried setting the pre

Re: part 2 of: SSL not working after unwanted server migration

[Robert Chalmers]

Where/what is the -D in your master.cf file 




> On 11 Dec 2018, at 14:35, Marco Fioretti  wrote:
> 
> /etc/postfix/master.cf: unused
> parameter: flags=D"

Robert Chalmers
https://robert-chalmers.uk
aut...@robert-chalmers.uk
@R_A_Chalmers

Re: part 2 of: SSL not working after unwanted server migration

[Robert Chalmers]

Do a 
postconf -Mf

to show your master.cf file configuration.



> On 11 Dec 2018, at 14:47, Robert Chalmers  wrote:
> 
> Where/what is the -D in your master.cf file 
> 
> 
> 
> 
>> On 11 Dec 2018, at 14:35, Marco Fioretti > > wrote:
>> 
>> /etc/postfix/master.cf: unused
>> parameter: flags=D"

Re: part 2 of: SSL not working after unwanted server migration

[Marco Fioretti]

here it is:

postconf -Mf
smtp   inet  n   -   n   -   -   smtpd
submission inet  n   -   n   -   -   smtpd
-o smtpd_enforce_tls=yes -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
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
628inet  n   -   n   -   -   qmqpd
pickup fifo  n   -   n   60  1   pickup
cleanupunix  n   -   n   -   0   cleanup
qmgr   fifo  n   -   n   300 1   qmgr
tlsmgr unix  -   -   n   1000?   1   tlsmgr
rewriteunix  -   -   n   -   -   trivial-rewrite
bounce unix  -   -   n   -   0   bounce
defer  unix  -   -   n   -   0   bounce
trace  unix  -   -   n   -   0   bounce
verify unix  -   -   n   -   1   verify
flush  unix  n   -   n   1000?   0   flush
proxymap   unix  -   -   n   -   -   proxymap
smtp   unix  -   -   n   -   -   smtp
relay  unix  -   -   n   -   -   smtp
-o fallback_relay=
showq  unix  n   -   n   -   -   showq
error  unix  -   -   n   -   -   error
retry  unix  -   -   n   -   -   error
discardunix  -   -   n   -   -   discard
local  unix  -   n   n   -   -   local
virtualunix  -   n   n   -   -   virtual
lmtp   unix  -   -   n   -   -   lmtp
anvil  unix  -   -   n   -   1   anvil
scache unix  -   -   n   -   1   scache
procmail   unix  -   n   n   -   -   pipe -o flags=D
user=myvmail_user argv=/usr/bin/procmail -t -m USER=${recipient}
EXTENSION=${extension} /usr/local/etc/procmailrc.common
here it
Il giorno mar 11 dic 2018 alle ore 15:51 Robert Chalmers
 ha scritto:
>
> Do a
> postconf -Mf
>
> to show your master.cf file configuration.
>
>
>
> On 11 Dec 2018, at 14:47, Robert Chalmers  wrote:
>
> Where/what is the -D in your master.cf file 
>
>
>
>
> On 11 Dec 2018, at 14:35, Marco Fioretti  wrote:
>
> /etc/postfix/master.cf: unused
> parameter: flags=D"
>
>
>

Re: Strange TLS error when sending mail from one server to my Postfix SMTP server

[Sean Son]

On Mon, Dec 10, 2018 at 9:40 PM Viktor Dukhovni 
wrote:

> > On Dec 10, 2018, at 8:00 PM, Sean Son 
> wrote:
> >
> > Thank you for the reply.  Can the client be configured to trust more
> than one SSL cert?
>
> You've told us nothing about the client, so it would be a miracle
> if someone on the list could give an answer to that question.
>
> Is the client running Postfix?  What sort of certificate chain
> does the server have? ...
>
> This is something you should be able to determine from the client
> software documentation, and by checking the server's certificate
> chain.
>
> --
> Viktor.
>
>
Hello Viktor

If, by "client", you mean the SMTP server, it is running Postfix.   The
client server is using a self signed cert and it is set up to offer STARTLS
to any senders who request TLS.   As for the sending server, the monitoring
application server that is, it is using a wild card certificate with a
bundled cert containing the intermediate certificate.


Thanks

Re: part 2 of: SSL not working after unwanted server migration

[Robert Chalmers]

So if you look carefully at master.cf, you will see that somewhere you have a 
stray “-D” attached to something.

Do you use vi to edit?

Open master.cf and use 
/-D

That will search for it?

Robert


> On 11 Dec 2018, at 14:57, Marco Fioretti  wrote:
> 
> here it is:
> 
> postconf -Mf
> smtp   inet  n   -   n   -   -   smtpd
> submission inet  n   -   n   -   -   smtpd
>-o smtpd_enforce_tls=yes -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
>-o smtpd_client_restrictions=permit_sasl_authenticated,reject
> 628inet  n   -   n   -   -   qmqpd
> pickup fifo  n   -   n   60  1   pickup
> cleanupunix  n   -   n   -   0   cleanup
> qmgr   fifo  n   -   n   300 1   qmgr
> tlsmgr unix  -   -   n   1000?   1   tlsmgr
> rewriteunix  -   -   n   -   -   trivial-rewrite
> bounce unix  -   -   n   -   0   bounce
> defer  unix  -   -   n   -   0   bounce
> trace  unix  -   -   n   -   0   bounce
> verify unix  -   -   n   -   1   verify
> flush  unix  n   -   n   1000?   0   flush
> proxymap   unix  -   -   n   -   -   proxymap
> smtp   unix  -   -   n   -   -   smtp
> relay  unix  -   -   n   -   -   smtp
>-o fallback_relay=
> showq  unix  n   -   n   -   -   showq
> error  unix  -   -   n   -   -   error
> retry  unix  -   -   n   -   -   error
> discardunix  -   -   n   -   -   discard
> local  unix  -   n   n   -   -   local
> virtualunix  -   n   n   -   -   virtual
> lmtp   unix  -   -   n   -   -   lmtp
> anvil  unix  -   -   n   -   1   anvil
> scache unix  -   -   n   -   1   scache
> procmail   unix  -   n   n   -   -   pipe -o flags=D
>user=myvmail_user argv=/usr/bin/procmail -t -m USER=${recipient}
>EXTENSION=${extension} /usr/local/etc/procmailrc.common
> here it
> Il giorno mar 11 dic 2018 alle ore 15:51 Robert Chalmers
>  ha scritto:
>> 
>> Do a
>> postconf -Mf
>> 
>> to show your master.cf file configuration.
>> 
>> 
>> 
>> On 11 Dec 2018, at 14:47, Robert Chalmers  wrote:
>> 
>> Where/what is the -D in your master.cf file 
>> 
>> 
>> 
>> 
>> On 11 Dec 2018, at 14:35, Marco Fioretti  wrote:
>> 
>> /etc/postfix/master.cf: unused
>> parameter: flags=D"
>> 
>> 
>> 

Robert Chalmers
https://robert-chalmers.uk
aut...@robert-chalmers.uk
@R_A_Chalmers

Re: part 2 of: SSL not working after unwanted server migration

[Robert Chalmers]

You may actually have a -D where you should have a -d 





> On 11 Dec 2018, at 14:57, Marco Fioretti  wrote:
> 
> here it is:
> 
> postconf -Mf
> smtp   inet  n   -   n   -   -   smtpd
> submission inet  n   -   n   -   -   smtpd
>-o smtpd_enforce_tls=yes -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
>-o smtpd_client_restrictions=permit_sasl_authenticated,reject
> 628inet  n   -   n   -   -   qmqpd
> pickup fifo  n   -   n   60  1   pickup
> cleanupunix  n   -   n   -   0   cleanup
> qmgr   fifo  n   -   n   300 1   qmgr
> tlsmgr unix  -   -   n   1000?   1   tlsmgr
> rewriteunix  -   -   n   -   -   trivial-rewrite
> bounce unix  -   -   n   -   0   bounce
> defer  unix  -   -   n   -   0   bounce
> trace  unix  -   -   n   -   0   bounce
> verify unix  -   -   n   -   1   verify
> flush  unix  n   -   n   1000?   0   flush
> proxymap   unix  -   -   n   -   -   proxymap
> smtp   unix  -   -   n   -   -   smtp
> relay  unix  -   -   n   -   -   smtp
>-o fallback_relay=
> showq  unix  n   -   n   -   -   showq
> error  unix  -   -   n   -   -   error
> retry  unix  -   -   n   -   -   error
> discardunix  -   -   n   -   -   discard
> local  unix  -   n   n   -   -   local
> virtualunix  -   n   n   -   -   virtual
> lmtp   unix  -   -   n   -   -   lmtp
> anvil  unix  -   -   n   -   1   anvil
> scache unix  -   -   n   -   1   scache
> procmail   unix  -   n   n   -   -   pipe -o flags=D
>user=myvmail_user argv=/usr/bin/procmail -t -m USER=${recipient}
>EXTENSION=${extension} /usr/local/etc/procmailrc.common
> here it
> Il giorno mar 11 dic 2018 alle ore 15:51 Robert Chalmers
>  ha scritto:
>> 
>> Do a
>> postconf -Mf
>> 
>> to show your master.cf file configuration.
>> 
>> 
>> 
>> On 11 Dec 2018, at 14:47, Robert Chalmers  wrote:
>> 
>> Where/what is the -D in your master.cf file 
>> 
>> 
>> 
>> 
>> On 11 Dec 2018, at 14:35, Marco Fioretti  wrote:
>> 
>> /etc/postfix/master.cf: unused
>> parameter: flags=D"
>> 
>> 
>> 

Robert Chalmers
https://robert-chalmers.uk
aut...@robert-chalmers.uk
@R_A_Chalmers

Re: part 2 of: SSL not working after unwanted server migration

[Marco Fioretti]

Hello Robert,
there is no "-D" in master.cf, only "=D".
IN any case... I don't know what to answer.

By this I mean that I put together this procmail line in master.cf:

procmail  unix  -   n   n   -   -   pipe  -o
flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
USER=${recipient} EXTENSION=${extension}
/usr/local/etc/procmailrc.common

(with "=D", not "-D") maybe 10 years ago, in order to filter all
incoming email with procmail, following advice from procmail and
postfix mailing lists. Since then, and until 4 days ago, it had always
worked as expected, and never given me reasons to remember its
existence. Do you mean that the "flags=D" setting is obsolete in the
current version of postfix?

Marco
Il giorno mar 11 dic 2018 alle ore 16:36 Robert Chalmers
 ha scritto:
>
> You may actually have a -D where you should have a -d 
>
>
>
>
>
> On 11 Dec 2018, at 14:57, Marco Fioretti  wrote:
>
> here it is:
>
> postconf -Mf
> smtp   inet  n   -   n   -   -   smtpd
> submission inet  n   -   n   -   -   smtpd
>-o smtpd_enforce_tls=yes -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
>-o smtpd_client_restrictions=permit_sasl_authenticated,reject
> 628inet  n   -   n   -   -   qmqpd
> pickup fifo  n   -   n   60  1   pickup
> cleanupunix  n   -   n   -   0   cleanup
> qmgr   fifo  n   -   n   300 1   qmgr
> tlsmgr unix  -   -   n   1000?   1   tlsmgr
> rewriteunix  -   -   n   -   -   trivial-rewrite
> bounce unix  -   -   n   -   0   bounce
> defer  unix  -   -   n   -   0   bounce
> trace  unix  -   -   n   -   0   bounce
> verify unix  -   -   n   -   1   verify
> flush  unix  n   -   n   1000?   0   flush
> proxymap   unix  -   -   n   -   -   proxymap
> smtp   unix  -   -   n   -   -   smtp
> relay  unix  -   -   n   -   -   smtp
>-o fallback_relay=
> showq  unix  n   -   n   -   -   showq
> error  unix  -   -   n   -   -   error
> retry  unix  -   -   n   -   -   error
> discardunix  -   -   n   -   -   discard
> local  unix  -   n   n   -   -   local
> virtualunix  -   n   n   -   -   virtual
> lmtp   unix  -   -   n   -   -   lmtp
> anvil  unix  -   -   n   -   1   anvil
> scache unix  -   -   n   -   1   scache
> procmail   unix  -   n   n   -   -   pipe -o flags=D
>user=myvmail_user argv=/usr/bin/procmail -t -m USER=${recipient}
>EXTENSION=${extension} /usr/local/etc/procmailrc.common
> here it
> Il giorno mar 11 dic 2018 alle ore 15:51 Robert Chalmers
>  ha scritto:
>
>
> Do a
> postconf -Mf
>
> to show your master.cf file configuration.
>
>
>
> On 11 Dec 2018, at 14:47, Robert Chalmers  wrote:
>
> Where/what is the -D in your master.cf file 
>
>
>
>
> On 11 Dec 2018, at 14:35, Marco Fioretti  wrote:
>
> /etc/postfix/master.cf: unused
> parameter: flags=D"
>
>
>
>
> Robert Chalmers
> https://robert-chalmers.uk
> aut...@robert-chalmers.uk
> @R_A_Chalmers
>

Re: part 2 of: SSL not working after unwanted server migration

[Robert Chalmers]

No no. That line is quite different.

-D is not it.
Are you starting master with a -D maybe.

Like /use/sbin/master -D type of thing?

Turn on verbose output with a -v and see if you can catch it.




-



> On 11 Dec 2018, at 3:49 pm, Marco Fioretti  wrote:
> 
> Hello Robert,
> there is no "-D" in master.cf, only "=D".
> IN any case... I don't know what to answer.
> 
> By this I mean that I put together this procmail line in master.cf:
> 
> procmail  unix  -   n   n   -   -   pipe  -o
> flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
> USER=${recipient} EXTENSION=${extension}
> /usr/local/etc/procmailrc.common
> 
> (with "=D", not "-D") maybe 10 years ago, in order to filter all
> incoming email with procmail, following advice from procmail and
> postfix mailing lists. Since then, and until 4 days ago, it had always
> worked as expected, and never given me reasons to remember its
> existence. Do you mean that the "flags=D" setting is obsolete in the
> current version of postfix?
> 
> Marco
> Il giorno mar 11 dic 2018 alle ore 16:36 Robert Chalmers
>  ha scritto:
>> 
>> You may actually have a -D where you should have a -d 
>> 
>> 
>> 
>> 
>> 
>> On 11 Dec 2018, at 14:57, Marco Fioretti  wrote:
>> 
>> here it is:
>> 
>> postconf -Mf
>> smtp   inet  n   -   n   -   -   smtpd
>> submission inet  n   -   n   -   -   smtpd
>>   -o smtpd_enforce_tls=yes -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
>>   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
>> 628inet  n   -   n   -   -   qmqpd
>> pickup fifo  n   -   n   60  1   pickup
>> cleanupunix  n   -   n   -   0   cleanup
>> qmgr   fifo  n   -   n   300 1   qmgr
>> tlsmgr unix  -   -   n   1000?   1   tlsmgr
>> rewriteunix  -   -   n   -   -   trivial-rewrite
>> bounce unix  -   -   n   -   0   bounce
>> defer  unix  -   -   n   -   0   bounce
>> trace  unix  -   -   n   -   0   bounce
>> verify unix  -   -   n   -   1   verify
>> flush  unix  n   -   n   1000?   0   flush
>> proxymap   unix  -   -   n   -   -   proxymap
>> smtp   unix  -   -   n   -   -   smtp
>> relay  unix  -   -   n   -   -   smtp
>>   -o fallback_relay=
>> showq  unix  n   -   n   -   -   showq
>> error  unix  -   -   n   -   -   error
>> retry  unix  -   -   n   -   -   error
>> discardunix  -   -   n   -   -   discard
>> local  unix  -   n   n   -   -   local
>> virtualunix  -   n   n   -   -   virtual
>> lmtp   unix  -   -   n   -   -   lmtp
>> anvil  unix  -   -   n   -   1   anvil
>> scache unix  -   -   n   -   1   scache
>> procmail   unix  -   n   n   -   -   pipe -o flags=D
>>   user=myvmail_user argv=/usr/bin/procmail -t -m USER=${recipient}
>>   EXTENSION=${extension} /usr/local/etc/procmailrc.common
>> here it
>> Il giorno mar 11 dic 2018 alle ore 15:51 Robert Chalmers
>>  ha scritto:
>> 
>> 
>> Do a
>> postconf -Mf
>> 
>> to show your master.cf file configuration.
>> 
>> 
>> 
>> On 11 Dec 2018, at 14:47, Robert Chalmers  wrote:
>> 
>> Where/what is the -D in your master.cf file 
>> 
>> 
>> 
>> 
>> On 11 Dec 2018, at 14:35, Marco Fioretti  wrote:
>> 
>> /etc/postfix/master.cf: unused
>> parameter: flags=D"
>> 
>> 
>> 
>> 
>> Robert Chalmers
>> https://robert-chalmers.uk
>> aut...@robert-chalmers.uk
>> @R_A_Chalmers
>> 

Re: Strange TLS error when sending mail from one server to my Postfix SMTP server

[Matus UHLAR - fantomas]

> On Dec 10, 2018, at 8:00 PM, Sean Son
>  wrote:
>
> Thank you for the reply.  Can the client be configured to trust more
> than one SSL cert?


most of clients support more than one certificate authority.


On Mon, Dec 10, 2018 at 9:40 PM Viktor Dukhovni 
wrote:

You've told us nothing about the client, so it would be a miracle
if someone on the list could give an answer to that question.

Is the client running Postfix?  What sort of certificate chain
does the server have? ...

This is something you should be able to determine from the client
software documentation, and by checking the server's certificate
chain.


On 11.12.18 10:21, Sean Son wrote:

If, by "client", you mean the SMTP server, it is running Postfix.


No. by "client" people usually mean the one who is connecting to server.
SMTP client connects to SMTP server etc.


The client server is using a self signed cert and it is set up to offer
STARTLS to any senders who request TLS.


I understand this as "SMTP server of your client"


As for the sending server, the monitoring application server that is, it
is using a wild card certificate with a bundled cert containing the
intermediate certificate.


if your monitoring application sends mail to another server, it's not
important what certificate your monitoring server uses, because it's not
used.

according to your original mail:


This server is set up with TLS enabled and it uses a script to send
email to any SMTP server that we choose.



Whenever I try to send mail from the monitoring
server to this postfix based SMTP server, using TLS, I get the following
strange errors in the maillog of the postfix server:


As I undertsand it, the script running on your monitoring server [x.x.x.75]
is trying to connect to your client's postfix server and fails.
Such script must accept certificate send by the postfix server.

Another possibility is that client application uses mail transfer agent
(MTA, e.g. postfix) installed on your monitoring server which further
passes the mail to your client's SMTP server.  In such case, this MTA must
accept certificate of your client's postfix server.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I intend to live forever - so far so good. 

Re: part 2 of: SSL not working after unwanted server migration

[Matus UHLAR - fantomas]

On 11.12.18 16:49, Marco Fioretti wrote:

there is no "-D" in master.cf, only "=D".
IN any case... I don't know what to answer.

By this I mean that I put together this procmail line in master.cf:

procmail  unix  -   n   n   -   -   pipe  -o
flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
USER=${recipient} EXTENSION=${extension}
/usr/local/etc/procmailrc.common


the "flags" is supposed to be indented, since it is continuation of
"procmail" line:


procmail  unix  -   n   n   -   -   pipe  -o
flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
USER=${recipient} EXTENSION=${extension}
/usr/local/etc/procmailrc.common


(with "=D", not "-D") maybe 10 years ago, in order to filter all
incoming email with procmail, following advice from procmail and
postfix mailing lists. Since then, and until 4 days ago, it had always
worked as expected, and never given me reasons to remember its
existence. Do you mean that the "flags=D" setting is obsolete in the
current version of postfix?


it's not obsolete, but the filtering through procmail like this apparently is.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
If Barbie is so popular, why do you have to buy her friends? 

Re: part 2 of: SSL not working after unwanted server migration

[Marco Fioretti]

I confess I do not know how to check that. The output of which command
should I turn verbose?

Thanks
Il giorno mar 11 dic 2018 alle ore 16:57 Robert Chalmers
 ha scritto:
>
>
> No no. That line is quite different.
>
> -D is not it.
> Are you starting master with a -D maybe.
>
> Like /use/sbin/master -D type of thing?
>
> Turn on verbose output with a -v and see if you can catch it.
>
>
>
>
> -
>
>
>
> > On 11 Dec 2018, at 3:49 pm, Marco Fioretti  wrote:
> >
> > Hello Robert,
> > there is no "-D" in master.cf, only "=D".
> > IN any case... I don't know what to answer.
> >
> > By this I mean that I put together this procmail line in master.cf:
> >
> > procmail  unix  -   n   n   -   -   pipe  -o
> > flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
> > USER=${recipient} EXTENSION=${extension}
> > /usr/local/etc/procmailrc.common
> >
> > (with "=D", not "-D") maybe 10 years ago, in order to filter all
> > incoming email with procmail, following advice from procmail and
> > postfix mailing lists. Since then, and until 4 days ago, it had always
> > worked as expected, and never given me reasons to remember its
> > existence. Do you mean that the "flags=D" setting is obsolete in the
> > current version of postfix?
> >
> > Marco
> > Il giorno mar 11 dic 2018 alle ore 16:36 Robert Chalmers
> >  ha scritto:
> >>
> >> You may actually have a -D where you should have a -d 
> >>
> >>
> >>
> >>
> >>
> >> On 11 Dec 2018, at 14:57, Marco Fioretti  wrote:
> >>
> >> here it is:
> >>
> >> postconf -Mf
> >> smtp   inet  n   -   n   -   -   smtpd
> >> submission inet  n   -   n   -   -   smtpd
> >>   -o smtpd_enforce_tls=yes -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
> >>   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
> >> 628inet  n   -   n   -   -   qmqpd
> >> pickup fifo  n   -   n   60  1   pickup
> >> cleanupunix  n   -   n   -   0   cleanup
> >> qmgr   fifo  n   -   n   300 1   qmgr
> >> tlsmgr unix  -   -   n   1000?   1   tlsmgr
> >> rewriteunix  -   -   n   -   -   trivial-rewrite
> >> bounce unix  -   -   n   -   0   bounce
> >> defer  unix  -   -   n   -   0   bounce
> >> trace  unix  -   -   n   -   0   bounce
> >> verify unix  -   -   n   -   1   verify
> >> flush  unix  n   -   n   1000?   0   flush
> >> proxymap   unix  -   -   n   -   -   proxymap
> >> smtp   unix  -   -   n   -   -   smtp
> >> relay  unix  -   -   n   -   -   smtp
> >>   -o fallback_relay=
> >> showq  unix  n   -   n   -   -   showq
> >> error  unix  -   -   n   -   -   error
> >> retry  unix  -   -   n   -   -   error
> >> discardunix  -   -   n   -   -   discard
> >> local  unix  -   n   n   -   -   local
> >> virtualunix  -   n   n   -   -   virtual
> >> lmtp   unix  -   -   n   -   -   lmtp
> >> anvil  unix  -   -   n   -   1   anvil
> >> scache unix  -   -   n   -   1   scache
> >> procmail   unix  -   n   n   -   -   pipe -o flags=D
> >>   user=myvmail_user argv=/usr/bin/procmail -t -m USER=${recipient}
> >>   EXTENSION=${extension} /usr/local/etc/procmailrc.common
> >> here it
> >> Il giorno mar 11 dic 2018 alle ore 15:51 Robert Chalmers
> >>  ha scritto:
> >>
> >>
> >> Do a
> >> postconf -Mf
> >>
> >> to show your master.cf file configuration.
> >>
> >>
> >>
> >> On 11 Dec 2018, at 14:47, Robert Chalmers  wrote:
> >>
> >> Where/what is the -D in your master.cf file 
> >>
> >>
> >>
> >>
> >> On 11 Dec 2018, at 14:35, Marco Fioretti  wrote:
> >>
> >> /etc/postfix/master.cf: unused
> >> parameter: flags=D"
> >>
> >>
> >>
> >>
> >> Robert Chalmers
> >> https://robert-chalmers.uk
> >> aut...@robert-chalmers.uk
> >> @R_A_Chalmers
> >>

Re: part 2 of: SSL not working after unwanted server migration

[Robert Chalmers]

Hi
I misread the output of postconf above

returns ~10 warnings all equal to " /etc/postfix/master.cf: unused
parameter: flags=D"

Remove the ‘flags=D’ and restart. Then do a post one -MF again

Remember, you have to restart postfix to load master, not just reload.

Robert



__
Robert Chalmers
https://robert-chalmers.uk
aut...@robert-chalmers.uk
@R_A_Chalmers

> On 11 Dec 2018, at 4:12 pm, Marco Fioretti  wrote:
> 
> I confess I do not know how to check that. The output of which command
> should I turn verbose?
> 
> Thanks
> Il giorno mar 11 dic 2018 alle ore 16:57 Robert Chalmers
>  ha scritto:
>> 
>> 
>> No no. That line is quite different.
>> 
>> -D is not it.
>> Are you starting master with a -D maybe.
>> 
>> Like /use/sbin/master -D type of thing?
>> 
>> Turn on verbose output with a -v and see if you can catch it.
>> 
>> 
>> 
>> 
>> -
>> 
>> 
>> 
>>> On 11 Dec 2018, at 3:49 pm, Marco Fioretti  wrote:
>>> 
>>> Hello Robert,
>>> there is no "-D" in master.cf, only "=D".
>>> IN any case... I don't know what to answer.
>>> 
>>> By this I mean that I put together this procmail line in master.cf:
>>> 
>>> procmail  unix  -   n   n   -   -   pipe  -o
>>> flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
>>> USER=${recipient} EXTENSION=${extension}
>>> /usr/local/etc/procmailrc.common
>>> 
>>> (with "=D", not "-D") maybe 10 years ago, in order to filter all
>>> incoming email with procmail, following advice from procmail and
>>> postfix mailing lists. Since then, and until 4 days ago, it had always
>>> worked as expected, and never given me reasons to remember its
>>> existence. Do you mean that the "flags=D" setting is obsolete in the
>>> current version of postfix?
>>> 
>>> Marco
>>> Il giorno mar 11 dic 2018 alle ore 16:36 Robert Chalmers
>>>  ha scritto:
 
 You may actually have a -D where you should have a -d 
 
 
 
 
 
 On 11 Dec 2018, at 14:57, Marco Fioretti  wrote:
 
 here it is:
 
 postconf -Mf
 smtp   inet  n   -   n   -   -   smtpd
 submission inet  n   -   n   -   -   smtpd
  -o smtpd_enforce_tls=yes -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
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
 628inet  n   -   n   -   -   qmqpd
 pickup fifo  n   -   n   60  1   pickup
 cleanupunix  n   -   n   -   0   cleanup
 qmgr   fifo  n   -   n   300 1   qmgr
 tlsmgr unix  -   -   n   1000?   1   tlsmgr
 rewriteunix  -   -   n   -   -   trivial-rewrite
 bounce unix  -   -   n   -   0   bounce
 defer  unix  -   -   n   -   0   bounce
 trace  unix  -   -   n   -   0   bounce
 verify unix  -   -   n   -   1   verify
 flush  unix  n   -   n   1000?   0   flush
 proxymap   unix  -   -   n   -   -   proxymap
 smtp   unix  -   -   n   -   -   smtp
 relay  unix  -   -   n   -   -   smtp
  -o fallback_relay=
 showq  unix  n   -   n   -   -   showq
 error  unix  -   -   n   -   -   error
 retry  unix  -   -   n   -   -   error
 discardunix  -   -   n   -   -   discard
 local  unix  -   n   n   -   -   local
 virtualunix  -   n   n   -   -   virtual
 lmtp   unix  -   -   n   -   -   lmtp
 anvil  unix  -   -   n   -   1   anvil
 scache unix  -   -   n   -   1   scache
 procmail   unix  -   n   n   -   -   pipe -o flags=D
  user=myvmail_user argv=/usr/bin/procmail -t -m USER=${recipient}
  EXTENSION=${extension} /usr/local/etc/procmailrc.common
 here it
 Il giorno mar 11 dic 2018 alle ore 15:51 Robert Chalmers
  ha scritto:
 
 
 Do a
 postconf -Mf
 
 to show your master.cf file configuration.
 
 
 
 On 11 Dec 2018, at 14:47, Robert Chalmers  wrote:
 
 Where/what is the -D in your master.cf file 
 
 
 
 
 On 11 Dec 2018, at 14:35, Marco Fioretti  wrote:
 
 /etc/postfix/master.cf: unused
 parameter: flags=D"
 
 
 
 
 Robert Chalmers
 https://robert-chalmers.uk
 aut...@robert-chalmers.uk
 @R_A_Chalmers
 

Re: part 2 of: SSL not working after unwanted server migration

[Marco Fioretti]

OK, I removed that part of the procmail line, and restarted. Here is
output of postconf -Mf and, respectively, postconf -n

(just for my own knowledge: this has nothing to do with the ipv6
complaints from google, or has it?)

Thanks,
Marco

###

smtp   inet  n   -   n   -   -   smtpd
submission inet  n   -   n   -   -   smtpd
-o smtpd_enforce_tls=yes -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
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
628inet  n   -   n   -   -   qmqpd
pickup fifo  n   -   n   60  1   pickup
cleanupunix  n   -   n   -   0   cleanup
qmgr   fifo  n   -   n   300 1   qmgr
tlsmgr unix  -   -   n   1000?   1   tlsmgr
rewriteunix  -   -   n   -   -   trivial-rewrite
bounce unix  -   -   n   -   0   bounce
defer  unix  -   -   n   -   0   bounce
trace  unix  -   -   n   -   0   bounce
verify unix  -   -   n   -   1   verify
flush  unix  n   -   n   1000?   0   flush
proxymap   unix  -   -   n   -   -   proxymap
smtp   unix  -   -   n   -   -   smtp
relay  unix  -   -   n   -   -   smtp
-o fallback_relay=
showq  unix  n   -   n   -   -   showq
error  unix  -   -   n   -   -   error
retry  unix  -   -   n   -   -   error
discardunix  -   -   n   -   -   discard
local  unix  -   n   n   -   -   local
virtualunix  -   n   n   -   -   virtual
lmtp   unix  -   -   n   -   -   lmtp
anvil  unix  -   -   n   -   1   anvil
scache unix  -   -   n   -   1   scache
procmail   unix  -   n   n   -   -   pipe
-o user=myvmail_user argv=/usr/bin/procmail -t -m USER=${recipient}
EXTENSION=${extension} /usr/local/etc/procmailrc.common


##

postconf -n

47.53.159.60
Il giorno mar 11 dic 2018 alle ore 17:26 Robert Chalmers
 ha scritto:
>
> Hi
> I misread the output of postconf above
>
> returns ~10 warnings all equal to " /etc/postfix/master.cf: unused
> parameter: flags=D"
>
> Remove the ‘flags=D’ and restart. Then do a post one -MF again
>
> Remember, you have to restart postfix to load master, not just reload.
>
> Robert
>
>
>
> __
> Robert Chalmers
> https://robert-chalmers.uk
> aut...@robert-chalmers.uk
> @R_A_Chalmers
>
> On 11 Dec 2018, at 4:12 pm, Marco Fioretti  wrote:
>
> I confess I do not know how to check that. The output of which command
> should I turn verbose?
>
> Thanks
> Il giorno mar 11 dic 2018 alle ore 16:57 Robert Chalmers
>  ha scritto:
>
>
>
> No no. That line is quite different.
>
>
> -D is not it.
>
> Are you starting master with a -D maybe.
>
>
> Like /use/sbin/master -D type of thing?
>
>
> Turn on verbose output with a -v and see if you can catch it.
>
>
>
>
>
> -
>
>
>
>
> On 11 Dec 2018, at 3:49 pm, Marco Fioretti  wrote:
>
>
> Hello Robert,
>
> there is no "-D" in master.cf, only "=D".
>
> IN any case... I don't know what to answer.
>
>
> By this I mean that I put together this procmail line in master.cf:
>
>
> procmail  unix  -   n   n   -   -   pipe  -o
>
> flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
>
> USER=${recipient} EXTENSION=${extension}
>
> /usr/local/etc/procmailrc.common
>
>
> (with "=D", not "-D") maybe 10 years ago, in order to filter all
>
> incoming email with procmail, following advice from procmail and
>
> postfix mailing lists. Since then, and until 4 days ago, it had always
>
> worked as expected, and never given me reasons to remember its
>
> existence. Do you mean that the "flags=D" setting is obsolete in the
>
> current version of postfix?
>
>
> Marco
>
> Il giorno mar 11 dic 2018 alle ore 16:36 Robert Chalmers
>
>  ha scritto:
>
>
> You may actually have a -D where you should have a -d 
>
>
>
>
>
>
> On 11 Dec 2018, at 14:57, Marco Fioretti  wrote:
>
>
> here it is:
>
>
> postconf -Mf
>
> smtp   inet  n   -   n   -   -   smtpd
>
> submission inet  n   -   n   -   -   smtpd
>
>  -o smtpd_enforce_tls=yes -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
>
>  -o smt

Re: part 2 of: SSL not working after unwanted server migration

[Marco Fioretti]

Il giorno mar 11 dic 2018 alle ore 17:03 Matus UHLAR - fantomas
 ha scritto:

> the "flags" is supposed to be indented, since it is continuation of
> "procmail" line:
>
>
> procmail  unix  -   n   n   -   -   pipe  -o
> flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
> USER=${recipient} EXTENSION=${extension}
> /usr/local/etc/procmailrc.common

maybe it came out as indented when copying/pasting/replying in email,
but it is NOT indented in the file. All that stuff has been on one line for,
as I said, ~10 years now.
> ... Do you mean that the "flags=D" setting is obsolete in the
> >current version of postfix?
>
> it's not obsolete, but the filtering through procmail like this apparently is.

OK, as long as the functionality remains the same, I certainly don't mind
removing that part of the line!

But if you check the output of postconf -Mf that I posted a few minutes ago...
now the question becomes "why there is a warning about "user=myvmail_user"?

As far as I can see, this postfix+procmail part of the system is
working as expected now. It
is "only" gmail interfacing and webmail configuration that are still giving me
pains.

Marco

Re: part 2 of: SSL not working after unwanted server migration

[Robert Chalmers]

Ok, I see no warnings in your 
postconf -Mf  ???

It looks good to me.

If that ip address you show is your’s, then you will never have a valid PTR 
record on it, because it belongs to your ISP.

host 47.53.159.60
60.159.53.47.in-addr.arpa domain name pointer 
net-47-53-159-60.cust.vodafonedsl.it.

dig +short net-47-53-159-60.cust.vodafonedsl.it
47.53.159.60


Gmail interfacing is always difficult. If you are running ipv6, and don’t need 
it, turn it off. Maybe Gmail will be ok then

robert






> On 11 Dec 2018, at 16:52, Marco Fioretti  wrote:
> 
> Il giorno mar 11 dic 2018 alle ore 17:03 Matus UHLAR - fantomas
>  ha scritto:
> 
>> the "flags" is supposed to be indented, since it is continuation of
>> "procmail" line:
>> 
>> 
>> procmail  unix  -   n   n   -   -   pipe  -o
>>flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
>>USER=${recipient} EXTENSION=${extension}
>>/usr/local/etc/procmailrc.common
> 
> maybe it came out as indented when copying/pasting/replying in email,
> but it is NOT indented in the file. All that stuff has been on one line for,
> as I said, ~10 years now.
>> ... Do you mean that the "flags=D" setting is obsolete in the
>>> current version of postfix?
>> 
>> it's not obsolete, but the filtering through procmail like this apparently 
>> is.
> 
> OK, as long as the functionality remains the same, I certainly don't mind
> removing that part of the line!
> 
> But if you check the output of postconf -Mf that I posted a few minutes ago...
> now the question becomes "why there is a warning about "user=myvmail_user"?
> 
> As far as I can see, this postfix+procmail part of the system is
> working as expected now. It
> is "only" gmail interfacing and webmail configuration that are still giving me
> pains.
> 
> Marco

Robert Chalmers
https://robert-chalmers.uk
aut...@robert-chalmers.uk
@R_A_Chalmers

Re: part 2 of: SSL not working after unwanted server migration

[Viktor Dukhovni]

> On Dec 11, 2018, at 10:49 AM, Marco Fioretti  wrote:
> 
> procmail  unix  -   n   n   -   -   pipe  -o
> flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
> USER=${recipient} EXTENSION=${extension}
> /usr/local/etc/procmailrc.common

The syntax is wrong, the "-o" is not followed by any valid main.cf parameter
override. The "flags=" parameter to pipe(8) is not a main.cf parameter.

The solution is to remove the dangling "-o".

In the meantime, you still HAVE NOT posted the logs that show smtpd(8)
complaining about being unable to initialize TLS.

If your SMTP server has no TLS, the reason is log early in process
startup, before any connections are processed.  Therefore, do not
post connection logs, but post warnings logged at process start.

-- 
Viktor.

Re: part 2 of: SSL not working after unwanted server migration

[Marco Fioretti]

OK, let's wait for the PTR record. After all, one of the advantages of
email is that it is not real time, right?

One thing I still have not clear, however, is what I reported about
the mismatch between example.com in the DNS records, and
a.mx.example.com as value of $myhostname. Comments on that? Postconf
-n is below , sorry that I forgot it earlier.

back to the master.cf configuration: as soon as I removed the
"flags=D" part, I started getting the errors below, so I put it back.
Your comments are welcome, I confess I'm totally lost on this bit.
Apart from being sure that a postconf warning is much less important
than email not being filtered, that is...

postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
disable_vrfy_command = yes
html_directory = /usr/share/doc/postfix-2.4.3-documentation/html
inet_interfaces = all
inet_protocols = ipv6, ipv4
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost
mydomain = $myhostname
myhostname = a.mx.example.com
mynetworks = 127.0.0.0/8, myhomeipaddress
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = inet:localhost:8891
procmail_destination_recipient_limit = 1
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme
relay_domains =
sample_directory = /etc/postfix
sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_address_preference = ipv6
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter =
smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_type = cyrus
smtp_sender_dependent_authentication = yes
smtp_tls_mandatory_ciphers = high
smtp_tls_security_level = may
smtpd_helo_required = yes
smtpd_helo_restrictions =
smtpd_milters = inet:localhost:8891
smtpd_recipient_restrictions = check_client_access
cidr:/etc/postfix/client_checks, reject_invalid_hostname,
reject_non_fqdn_hostname, reject_non_fqdn_sender,
reject_non_fqdn_recipient, reject_unknown_sender_domain,
reject_unknown_recipient_domain, permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
check_helo_access hash:/etc/postfix/reject_own_helo,
check_policy_service unix:postgrey/socket
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = /var/spool/postfix/private/auth
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/archive/example.com/fullchain1.pem
smtpd_tls_ciphers = medium
smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL
smtpd_tls_key_file = /etc/letsencrypt/archive/example.com/privkey1.pem
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
smtpd_use_tls = yes
strict_rfc821_envelopes = yes
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/mail/mymail_storage
virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map
virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map
virtual_transport = procmail
virtual_uid_maps = static:1001



ERRORS after removing "flags=D" from the procmail line in master.cf:

Dec 11 17:41:00 example.com postfix/qmgr[30169]: warning:
private/procmail socket: malformed response
Dec 11 17:41:00 example.com postfix/qmgr[30169]: warning: transport
procmail failure -- see a previous warning/fatal/panic logfile record
for th
e problem description
Dec 11 17:41:00 example.com postfix/master[30167]: warning: process
/usr/libexec/postfix/pipe pid 30219 exit status 1
Dec 11 17:41:00 example.com postfix/master[30167]: warning:
/usr/libexec/postfix/pipe: bad command startup -- throttling
Dec 11 17:41:00 example.com postfix/error[30220]: B9FB01F797:
to=, relay=none, delay=1.2, delays=0.19/1/0/0.02,
dsn=4.3.0
, status=deferred (unknown mail transport error)
Il giorno mar 11 dic 2018 alle ore 17:54 Robert Chalmers
 ha scritto:
>
> Ok,
> Looking better.
>
> And no. Nothing to do with Google.
> If you have your PTR record configured properly, it could take up to 24 or 
> even 48 hours to propagate. It shouldn’t but it can.
>
> So just be patient on that one for now :-)
>
> You didn’t include the postconf -n by the way...
>
> Robert
>
>
>
>
>
>
> __
> Robert Chalmers
> https://robert-chalmers.uk
> aut...@robert-chalmers.uk
> @R_A_Chalmers
>
> On 11 Dec 2018, at 4:44 pm, Marco Fioretti  wrote:
>
> OK, I removed that part of the procmail line, and restarted. Here is
> output of postconf -Mf

Re: part 2 of: SSL not working after unwanted server migration

[Marco Fioretti]

the 47.53.. address is only the current address of my home laptop. The
server we are talking about is a VPS in a datacentre. And reverse
lookup of the IPv4 and v6 addresses of that server already both return
the domain name "example.com", which as I said is not exactly the same
as the value of $myhostname, which is "a.mx.example.com" and makes me
suspect that may be the problem, rather than delays in dns
propagation.

by "turning ipv6 off" I assume you mean changing "inet_protocols =
ipv6, ipv4" to "inet_protocols = ipv4"  and commenting out
"smtp_address_preference = ipv6", I guess?

Thanks
Il giorno mar 11 dic 2018 alle ore 18:09 Robert Chalmers
 ha scritto:
>
>
> Ok, I see no warnings in your
> postconf -Mf  ???
>
> It looks good to me.
>
> If that ip address you show is your’s, then you will never have a valid PTR 
> record on it, because it belongs to your ISP.
>
> host 47.53.159.60
> 60.159.53.47.in-addr.arpa domain name pointer 
> net-47-53-159-60.cust.vodafonedsl.it.
>
> dig +short net-47-53-159-60.cust.vodafonedsl.it
> 47.53.159.60
>
>
> Gmail interfacing is always difficult. If you are running ipv6, and don’t 
> need it, turn it off. Maybe Gmail will be ok then
>
> robert
>
>
>
>
>
>
> > On 11 Dec 2018, at 16:52, Marco Fioretti  wrote:
> >
> > Il giorno mar 11 dic 2018 alle ore 17:03 Matus UHLAR - fantomas
> >  ha scritto:
> >
> >> the "flags" is supposed to be indented, since it is continuation of
> >> "procmail" line:
> >>
> >>
> >> procmail  unix  -   n   n   -   -   pipe  -o
> >>flags=D user=myvmail_user argv=/usr/bin/procmail -t -m
> >>USER=${recipient} EXTENSION=${extension}
> >>/usr/local/etc/procmailrc.common
> >
> > maybe it came out as indented when copying/pasting/replying in email,
> > but it is NOT indented in the file. All that stuff has been on one line for,
> > as I said, ~10 years now.
> >> ... Do you mean that the "flags=D" setting is obsolete in the
> >>> current version of postfix?
> >>
> >> it's not obsolete, but the filtering through procmail like this apparently 
> >> is.
> >
> > OK, as long as the functionality remains the same, I certainly don't mind
> > removing that part of the line!
> >
> > But if you check the output of postconf -Mf that I posted a few minutes 
> > ago...
> > now the question becomes "why there is a warning about "user=myvmail_user"?
> >
> > As far as I can see, this postfix+procmail part of the system is
> > working as expected now. It
> > is "only" gmail interfacing and webmail configuration that are still giving 
> > me
> > pains.
> >
> > Marco
>
> Robert Chalmers
> https://robert-chalmers.uk
> aut...@robert-chalmers.uk
> @R_A_Chalmers
>

Re: part 2 of: SSL not working after unwanted server migration

[Marco Fioretti]

Hello Viktor, and thanks for this:

> The syntax is wrong, the "-o" is not followed by any valid main.cf parameter
> override. The "flags=" parameter to pipe(8) is not a main.cf parameter.
>
> The solution is to remove the dangling "-o".

I confirm that doing so removes the warning in postconf -n, but keeps
procmail working properly. So even this part of the puzzle is solved.

About this:

> In the meantime, you still HAVE NOT posted the logs that show smtpd(8)
> complaining about being unable to initialize TLS.

right now, my brain is toast from trying to do both normal work AND this
in parallel (allow me to say again that this migration fell
on me with no notice at all). THerefore, I have very likely missed
that particular
request so far.

This said, I have checked /var/log/maillog. IN the last 3/4 hours,
that is after the changes suggested earlier by Robert and others, I
have restarted postfix 15/20 times, and the only lines that contain
the "postfix/smtpd" and a warning or error message are of two types.
One is connection attempts from some spam server that are rejected
because that server 'does not resolve to address'.

The second type is the notifications from gmail that they won't accept
my email because of the ipv6 mismatch I already reported.

If I misunderstood what you are asking, please tell me where/how to
get it, no problem. Ditto if you want to receive the complete log
privately, without any editing.

Thanks in advance,
Marco

Almost done with new server, was: SSL not working after unwanted server migratio

[Marco Fioretti]

Hello!

first of all, thanks again to everybody who helped, both on and off-list!

Right now, the original SSL problems seem all gone, and after turning
off ipv6 even gmail started to accept my email. Now I can connect with
mutt from home, access mailboxes over imaps, send email using ssl/tls
to any domain I have been able to try.

To get there, I had as I said to turn off ipv6, as shown in postconf
-n output below. Honestly, I have no idea if and what exactly I am
missing by not using ipv6, thanks in advance to whoever steps in to
explain.

In any case, I can say that the configuration below seems to be a
decent solution so far for running postfix 2.10 on Centos, for a small
number of users and domains, and without running any rdbms.

Next step is to figure out which between rainloop and roundcube is a
better/easier/safer webmail to set up.

General comments and/or tips on how to harden this, with stronger
ciphers or other stuff, are very welcome. Ditto for pointers to online
services to test if anything is OK wrt dkim, spf, dns, blacklists,
greylisting... (I DO know some of them, but not sure if they are the
most efficient). If anybody feels like receiving one email from that
server, just to confirm to me that everything is fine, please let me
know.

Thanks, and off to dinner and bed now...

Marco

postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
disable_vrfy_command = yes
html_directory = /usr/share/doc/postfix-2.4.3-documentation/html
inet_interfaces = all
inet_protocols = ipv4
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost
mydomain = $myhostname
myhostname = a.mx.example.com
mynetworks = 127.0.0.0/8, myhomeipaddress
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = inet:localhost:8891
procmail_destination_recipient_limit = 1
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme
relay_domains =
sample_directory = /etc/postfix
sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_address_preference = ipv4
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter =
smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_type = cyrus
smtp_sender_dependent_authentication = yes
smtp_tls_mandatory_ciphers = high
smtp_tls_security_level = may
smtpd_helo_required = yes
smtpd_helo_restrictions =
smtpd_milters = inet:localhost:8891
smtpd_recipient_restrictions = check_client_access
cidr:/etc/postfix/client_checks, reject_invalid_hostname,
reject_non_fqdn_hostname, reject_non_fqdn_sender,
reject_non_fqdn_recipient, reject_unknown_sender_domain,
reject_unknown_recipient_domain, permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
check_helo_access hash:/etc/postfix/reject_own_helo,
check_policy_service unix:postgrey/socket
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = /var/spool/postfix/private/auth
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/archive/example.com/fullchain1.pem
smtpd_tls_ciphers = medium
smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL
smtpd_tls_key_file = /etc/letsencrypt/archive/example.com/privkey1.pem
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
smtpd_use_tls = yes
strict_rfc821_envelopes = yes
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/mail/mymail_storage
virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map
virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map
virtual_transport = procmail
virtual_uid_maps = static:1001



postconf -Mf:

smtp   inet  n   -   n   -   -   smtpd
submission inet  n   -   n   -   -   smtpd
-o smtpd_enforce_tls=yes -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
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
628inet  n   -   n   -   -   qmqpd
pickup fifo  n   -   n   60  1   pickup
cleanupunix  n   -   n   -   0   cleanup
qmgr   fi

ignore SASL/Auth to specific server (internal exchange relay)

[Stefan Bauer]

Hi,

we receive mails from $world and forward them to internal exchange server.

Exchange is offering STARTTLS and AUTH

root@gate01:~# telnet 192.168.124.5 2525
Trying 192.168.124.5...
Connected to 192.168.124.5.
Escape character is '^]'.
220 ex01 Microsoft ESMTP MAIL Service ready at Tue, 11 Dec 2018 19:07:13
+0100
ehlo cubewerk.de
250-gate01 Hello [192.168.124.251]
250-SIZE
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH NTLM
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250-XRDST
250 XSHADOWREQUEST

Postfix gets ... during address verification.

Dec 11 19:27:18 postgate01 postfix/postscreen[583]: DISCONNECT
[client]:57636
Dec 11 19:27:18 postgate01 postfix/smtp[574]: 5586D101077: to=<
odf...@customer.de>, relay=192.168.124.5[192.168.124.5]:2525, delay=11,
delays=1/0.02/10/0, dsn=4.7.3, status=undeliverable (SASL authentication
failed; server 192.168.124.5[192.168.124.5] said: 535 5.7.3 Authentication
unsuccessful)

how can we ignore AUTH and STARTTLS and just go on?

telnet shows the dialog i expect:

outgoing mails get relayed through smarthost, so this is where all the
client tls settings interfere i guess :/

Re: ignore SASL/Auth to specific server (internal exchange relay)

[Wietse Venema]

Stefan Bauer:
> Hi,
> 
> we receive mails from $world and forward them to internal exchange server.
> 
> Exchange is offering STARTTLS and AUTH
> 
> root@gate01:~# telnet 192.168.124.5 2525
> Trying 192.168.124.5...
> Connected to 192.168.124.5.
> Escape character is '^]'.
> Dec 11 19:27:18 postgate01 postfix/postscreen[583]: DISCONNECT
> [client]:57636
> Dec 11 19:27:18 postgate01 postfix/smtp[574]: 5586D101077: to=<
> odf...@customer.de>, relay=192.168.124.5[192.168.124.5]:2525, delay=11,
> delays=1/0.02/10/0, dsn=4.7.3, status=undeliverable (SASL authentication
> failed; server 192.168.124.5[192.168.124.5] said: 535 5.7.3 Authentication
> unsuccessful)
> 
> how can we ignore AUTH and STARTTLS and just go on?

If you don't want Postfix to send AUTH to this server,
then do not configure Postfix to send AUTH to this server.

Woeyse

Re: ignore SASL/Auth to specific server (internal exchange relay)

[Stefan Bauer]

I dont see  a way to have AUTH&TLS to all of our relayhosts but not for
this internal hosts.

sender_dependent_relayhost_maps = hash:/etc/postfix/relayhost_maps
smtp_sender_dependent_authentication = yes
smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth
smtp_sasl_auth_enable = yes
smtp_tls_security_level = may
smtp_sasl_security_options = noanonymous

root@postgate01:/etc/postfix# more relayhost_maps
@domain1.de [securerelay.tld]:25
@domain2.de [securerelay.tld]:25


root@postgate01:/etc/postfix# more transport
domain1.de smtp:192.168.124.5:2525
domain2.de smtp:192.168.124.5:2525

So howto not use AUTH&TLS at all to 192.168.124.5:2525 ?


Am Di., 11. Dez. 2018 um 20:32 Uhr schrieb Wietse Venema <
wie...@porcupine.org>:

> Stefan Bauer:
> > Hi,
> >
> > we receive mails from $world and forward them to internal exchange
> server.
> >
> > Exchange is offering STARTTLS and AUTH
> >
> > root@gate01:~# telnet 192.168.124.5 2525
> > Trying 192.168.124.5...
> > Connected to 192.168.124.5.
> > Escape character is '^]'.
> > Dec 11 19:27:18 postgate01 postfix/postscreen[583]: DISCONNECT
> > [client]:57636
> > Dec 11 19:27:18 postgate01 postfix/smtp[574]: 5586D101077: to=<
> > odf...@customer.de>, relay=192.168.124.5[192.168.124.5]:2525, delay=11,
> > delays=1/0.02/10/0, dsn=4.7.3, status=undeliverable (SASL authentication
> > failed; server 192.168.124.5[192.168.124.5] said: 535 5.7.3
> Authentication
> > unsuccessful)
> >
> > how can we ignore AUTH and STARTTLS and just go on?
>
> If you don't want Postfix to send AUTH to this server,
> then do not configure Postfix to send AUTH to this server.
>
> Woeyse
>

Re: ignore SASL/Auth to specific server (internal exchange relay)

[Viktor Dukhovni]

To use host-specific rather than sender-dependent authentication,
you'll need a separate transport for the relay(s) in question,
with "smtp_sender_dependent_authentication = no" for that
transport.

> On Dec 11, 2018, at 2:37 PM, Stefan Bauer  wrote:
> 
> I dont see  a way to have AUTH&TLS to all of our relayhosts but not for this 
> internal hosts.
> 
> sender_dependent_relayhost_maps = hash:/etc/postfix/relayhost_maps
> smtp_sender_dependent_authentication = yes
> smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth
> smtp_sasl_auth_enable = yes
> smtp_tls_security_level = may
> smtp_sasl_security_options = noanonymous
> 
> root@postgate01:/etc/postfix# more relayhost_maps
> @domain1.de   [securerelay.tld]:25
> @domain2.de   [securerelay.tld]:25
> 

-- 
Viktor.

Re: ignore SASL/Auth to specific server (internal exchange relay)

[Stefan Bauer]

Can you recommend appropriate manual(s)? I dont understand what you mean
with separate transport.




Am Di., 11. Dez. 2018 um 21:20 Uhr schrieb Viktor Dukhovni <
postfix-us...@dukhovni.org>:

> To use host-specific rather than sender-dependent authentication,
> you'll need a separate transport for the relay(s) in question,
> with "smtp_sender_dependent_authentication = no" for that
> transport.
>
> > On Dec 11, 2018, at 2:37 PM, Stefan Bauer 
> wrote:
> >
> > I dont see  a way to have AUTH&TLS to all of our relayhosts but not for
> this internal hosts.
> >
> > sender_dependent_relayhost_maps = hash:/etc/postfix/relayhost_maps
> > smtp_sender_dependent_authentication = yes
> > smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth
> > smtp_sasl_auth_enable = yes
> > smtp_tls_security_level = may
> > smtp_sasl_security_options = noanonymous
> >
> > root@postgate01:/etc/postfix# more relayhost_maps
> > @domain1.de   [securerelay.tld]:25
> > @domain2.de   [securerelay.tld]:25
> >
>
> --
> Viktor.
>
>

Re: ignore SASL/Auth to specific server (internal exchange relay)

[Viktor Dukhovni]

> On Dec 11, 2018, at 3:41 PM, Stefan Bauer  wrote:
> 
> Can you recommend appropriate manual(s)? I dont understand what you mean with 
> separate transport.

http://www.postfix.org/master.5.html
http://www.postfix.org/transport.5.html
http://www.postfix.org/ADDRESS_REWRITING_README.html
http://www.postfix.org/FILTER_README.html#advanced_filter
  ( Advanced content filter: sending unfiltered mail to the content filter )

Also the Postfix book by Patrick Koetter and Ralf Hildebrandt.

-- 
Viktor.

Re: ignore SASL/Auth to specific server (internal exchange relay)

[Stefan Bauer]

thank you for your help!

If i understood you correctly, i set in transport:

domain1.deexchange:

In master.cf

exchange  unix -   -   n   -   -   smtp
 -o smtp_sender_dependent_authentication=no
 -o transport_maps=hash:/etc/postfix/transport_internal

And in transport_internal

domain1.desmtp:192.168.124.5:2525

but this way, postfix is doing a MX-lookup for domain1.de and not honoring
transport_internal as it seems.

Is this basically the right path?


Am Di., 11. Dez. 2018 um 21:48 Uhr schrieb Viktor Dukhovni <
postfix-us...@dukhovni.org>:

> > On Dec 11, 2018, at 3:41 PM, Stefan Bauer 
> wrote:
> >
> > Can you recommend appropriate manual(s)? I dont understand what you mean
> with separate transport.
>
> http://www.postfix.org/master.5.html
> http://www.postfix.org/transport.5.html
> http://www.postfix.org/ADDRESS_REWRITING_README.html
> http://www.postfix.org/FILTER_README.html#advanced_filter
>   ( Advanced content filter: sending unfiltered mail to the content filter
> )
>
> Also the Postfix book by Patrick Koetter and Ralf Hildebrandt.
>
> --
> Viktor.
>
>

Re: ignore SASL/Auth to specific server (internal exchange relay)

[Wietse Venema]

Stefan Bauer:
> thank you for your help!
> 
> If i understood you correctly, i set in transport:
> 
> domain1.deexchange:
> 
> In master.cf
> 
> exchange  unix -   -   n   -   -   smtp
>  -o smtp_sender_dependent_authentication=no
>  -o transport_maps=hash:/etc/postfix/transport_internal
> 
> And in transport_internal
> 
> domain1.desmtp:192.168.124.5:2525
> 
> but this way, postfix is doing a MX-lookup for domain1.de and not honoring
> transport_internal as it seems.

Transport map lookups happen before choosing the SMTP client,
therefore you made a mistake updating the transport map.

Try:
postmap -q domain1.de hash:/path/to/transport

Wietse

Re: ignore SASL/Auth to specific server (internal exchange relay)

[Viktor Dukhovni]

> On Dec 11, 2018, at 4:40 PM, Stefan Bauer  wrote:
> 
> exchange  unix -   -   n   -   -   smtp
>  -o smtp_sender_dependent_authentication=no
>  -o transport_maps=hash:/etc/postfix/transport_internal

No the "transport_maps" setting goes in main.cf.  Transport
lookups are global.

See: http://www.postfix.org/OVERVIEW.html

-- 
Viktor.

Re: ignore SASL/Auth to specific server (internal exchange relay)

[Stefan Bauer]

i already have a transport_maps in main.cf in place:
transport_maps=hash:/etc/postfix/transport

domain1.deexchange:

How can i set another  transport_maps setting in main.cf as you recommend?

Am Mi., 12. Dez. 2018 um 00:29 Uhr schrieb Viktor Dukhovni <
postfix-us...@dukhovni.org>:

> > On Dec 11, 2018, at 4:40 PM, Stefan Bauer 
> wrote:
> >
> > exchange  unix -   -   n   -   -   smtp
> >  -o smtp_sender_dependent_authentication=no
> >  -o transport_maps=hash:/etc/postfix/transport_internal
>
> No the "transport_maps" setting goes in main.cf.  Transport
> lookups are global.
>
> See: http://www.postfix.org/OVERVIEW.html
>
> --
> Viktor.
>
>