part 2 of: SSL not working after unwanted server migration

2018-12-11 Thread 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-Decembe

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

2018-12-11 Thread 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 t

Re: Treat only one address of a domain as local

2018-12-11 Thread 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'

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

2018-12-11 Thread 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 y

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

2018-12-11 Thread 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 do

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

2018-12-11 Thread 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 > r

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

2018-12-11 Thread 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 >

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

2018-12-11 Thread 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 so

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

2018-12-11 Thread 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

2018-12-11 Thread 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.

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

2018-12-11 Thread 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 smt

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

2018-12-11 Thread 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 li

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

2018-12-11 Thread 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

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

2018-12-11 Thread 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_enfor

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

2018-12-11 Thread 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=${re

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

2018-12-11 Thread 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 "

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

2018-12-11 Thread 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

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

2018-12-11 Thread 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

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

2018-12-11 Thread 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/mast

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

2018-12-11 Thread 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 Chal

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

2018-12-11 Thread 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

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

2018-12-11 Thread 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

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

2018-12-11 Thread 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

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

2018-12-11 Thread 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 f

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

2018-12-11 Thread 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?

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

2018-12-11 Thread 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 $myh

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

2018-12-11 Thread 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,

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

2018-12-11 Thread 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 an

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

2018-12-11 Thread 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

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

2018-12-11 Thread 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 postgat

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

2018-12-11 Thread 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_secu

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

2018-12-11 Thread 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 o

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

2018-12-11 Thread 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

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

2018-12-11 Thread 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

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

2018-12-11 Thread 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 tr

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

2018-12-11 Thread 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/p

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

2018-12-11 Thread 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 globa

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

2018-12-11 Thread 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>: