Re: Was the Dovecot working well?

[lists]

I've run scripts on my logs regarding login attempts. Typically they try 
"info@" since many websites have that account. (I don't.) They seem to "snow 
shoe" the attacks. Usually 3 guesses then they go away. The most I had was 5. 

Considering the IP address could be shared with someone not hacking, I figured 
it was a waste of time to set up any intelligent blocking. (And those on this 
list know I am paranoid.)

Note that sshguard can parse  the postfix log‎. I do let it do that, but don't 
use the sshguard table to block mail ports. Again, you could be blocking 
someone innocent. (I certainly block 22). I figure anyone hacking mail would 
hack ssh.

I suppose it wouldn't hurt to block submission with that table.

  Original Message  
From: Sean Greenslade
Sent: Monday, November 14, 2016 8:40 PM
To: vod vos
Cc: postfix-users
Subject: Re: Was the Dovecot working well?

On Mon, Nov 14, 2016 at 08:21:24PM -0800, vod vos wrote:
> so are there any configurations to auto ban this kind of visit, like postfix 
> postscreen?
> 
> or, I should write firewall rules to do the job?

I don't know if dovecot provides such functionality. I personally don't
bother, since it quickly becomes a game of whack-a-mole. Plus, it's not
always a malicious event. If the connection gets interrupted before the
client sends its auth credentials, it looks the same as this type of
scan.

Basically, make sure users are using good, secure passwords, and make
sure your software is all up to date.

--Sean

Re: Was the Dovecot working well?

[Sean Greenslade]

On Mon, Nov 14, 2016 at 08:21:24PM -0800, vod vos wrote:
> so are there any configurations to auto ban this kind of visit, like postfix 
> postscreen?
> 
> or, I should write firewall rules to do the job?

I don't know if dovecot provides such functionality. I personally don't
bother, since it quickly becomes a game of whack-a-mole. Plus, it's not
always a malicious event. If the connection gets interrupted before the
client sends its auth credentials, it looks the same as this type of
scan.

Basically, make sure users are using good, secure passwords, and make
sure your software is all up to date.

--Sean

Re: Was the Dovecot working well?

[vod vos]

so are there any configurations to auto ban this kind of visit, like postfix 
postscreen?



or, I should write firewall rules to do the job?




 On 星期一, 14 十一月 2016 19:23:53 -0800Sean Greenslade 
s...@seangreenslade.com wrote 




On Mon, Nov 14, 2016 at 06:39:08PM -0800, vod vos wrote: 

 Hi, 

 

 

 

 when I read the mail.log, I found: 

 

 

 

 

 

 Nov 14 14:45:45 mail dovecot: pop3-login: Disconnected (no auth attempts 
in 2 secs): user=lt;gt;, rip=96.126.111.38, lip=108.61.22.11, TLS 
handshaking: SSL_accept() syscall failed: Connection reset by peer, 
session=lt;WEd2MD1B/Mdgfm8mgt; 

 

 

 

 Nov 14 14:45:47 mail dovecot: pop3-login: Disconnected (no auth attempts 
in 2 secs): user=lt;gt;, rip=96.126.111.38, lip=108.61.22.11, TLS 
handshaking: SSL_accept() syscall failed: Connection reset by peer, 
session=lt;H42OMD1BZslgfm8mgt; 

 

 

 

 Nov 14 14:45:47 mail dovecot: pop3-login: Error: SSL: Stacked error: 
error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request 

 

 

 

 Nov 14 14:45:47 mail dovecot: pop3-login: Disconnected (no auth attempts 
in 0 secs): user=lt;gt;, rip=96.126.111.38, lip=108.61.22.11, TLS 
handshaking: SSL_accept() failed: Unknown error, 
session=lt;rQ6QMD1BxMpgfm8mgt; 

 

 

 

 Nov 14 14:45:47 mail dovecot: pop3-login: Error: SSL: Stacked error: 
error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version number 

 

 

 

 Nov 14 14:45:47 mail dovecot: pop3-login: Disconnected (no auth attempts 
in 0 secs): user=lt;gt;, rip=96.126.111.38, lip=108.61.22.11, TLS 
handshaking: SSL_accept() failed: Unknown error, 
session=lt;3DqTMD1BKstgfm8mgt; 

 

 

 

 Nov 14 14:45:49 mail dovecot: pop3-login: Disconnected (no auth attempts 
in 2 secs): user=lt;gt;, rip=96.126.111.38, lip=108.61.22.11, TLS, 
session=lt;CCqyMD1BdMtgfm8mgt; 

 

 

 

 Was the Dovecot working well? 

 

 Are there any good solutions to forbid this kind of behavior to enhance 
the mail server? 

 

Do you know whether these were actual login attempts? Because these 

look like typical port scans that you'll see from time to time. 

According to this site, that's an IP that's known for port scanning: 

 

https://www.abuseipdb.com/check/96.126.111.38 

 

I wouldn't worry too much about them. 

 

--Sean 

 

Re: Was the Dovecot working well?

[Sean Greenslade]

On Mon, Nov 14, 2016 at 06:39:08PM -0800, vod vos wrote:
> Hi,
> 
> 
> 
> when I read the mail.log, I found:
> 
> 
> 
> 
> 
> Nov 14 14:45:45 mail dovecot: pop3-login: Disconnected (no auth attempts in 2 
> secs): user=, rip=96.126.111.38, lip=108.61.22.11, TLS handshaking: 
> SSL_accept() syscall failed: Connection reset by peer, 
> session=WEd2MD1B/Mdgfm8m
> 
> 
> 
> Nov 14 14:45:47 mail dovecot: pop3-login: Disconnected (no auth attempts in 2 
> secs): user=, rip=96.126.111.38, lip=108.61.22.11, TLS handshaking: 
> SSL_accept() syscall failed: Connection reset by peer, 
> session=H42OMD1BZslgfm8m
> 
> 
> 
> Nov 14 14:45:47 mail dovecot: pop3-login: Error: SSL: Stacked error: 
> error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
> 
> 
> 
> Nov 14 14:45:47 mail dovecot: pop3-login: Disconnected (no auth attempts in 0 
> secs): user=, rip=96.126.111.38, lip=108.61.22.11, TLS handshaking: 
> SSL_accept() failed: Unknown error, session=rQ6QMD1BxMpgfm8m
> 
> 
> 
> Nov 14 14:45:47 mail dovecot: pop3-login: Error: SSL: Stacked error: 
> error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version number
> 
> 
> 
> Nov 14 14:45:47 mail dovecot: pop3-login: Disconnected (no auth attempts in 0 
> secs): user=, rip=96.126.111.38, lip=108.61.22.11, TLS handshaking: 
> SSL_accept() failed: Unknown error, session=3DqTMD1BKstgfm8m
> 
> 
> 
> Nov 14 14:45:49 mail dovecot: pop3-login: Disconnected (no auth attempts in 2 
> secs): user=, rip=96.126.111.38, lip=108.61.22.11, TLS, 
> session=CCqyMD1BdMtgfm8m
> 
> 
> 
> Was the Dovecot working well? 
> 
> Are there any good solutions to forbid this kind of behavior to enhance the 
> mail server?

Do you know whether these were actual login attempts? Because these
look like typical port scans that you'll see from time to time.
According to this site, that's an IP that's known for port scanning:

https://www.abuseipdb.com/check/96.126.111.38

I wouldn't worry too much about them.

--Sean

Was the Dovecot working well?

[vod vos]

Hi,



when I read the mail.log, I found:





Nov 14 14:45:45 mail dovecot: pop3-login: Disconnected (no auth attempts in 2 
secs): user=, rip=96.126.111.38, lip=108.61.22.11, TLS handshaking: 
SSL_accept() syscall failed: Connection reset by peer, 
session=WEd2MD1B/Mdgfm8m



Nov 14 14:45:47 mail dovecot: pop3-login: Disconnected (no auth attempts in 2 
secs): user=, rip=96.126.111.38, lip=108.61.22.11, TLS handshaking: 
SSL_accept() syscall failed: Connection reset by peer, 
session=H42OMD1BZslgfm8m



Nov 14 14:45:47 mail dovecot: pop3-login: Error: SSL: Stacked error: 
error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request



Nov 14 14:45:47 mail dovecot: pop3-login: Disconnected (no auth attempts in 0 
secs): user=, rip=96.126.111.38, lip=108.61.22.11, TLS handshaking: 
SSL_accept() failed: Unknown error, session=rQ6QMD1BxMpgfm8m



Nov 14 14:45:47 mail dovecot: pop3-login: Error: SSL: Stacked error: 
error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version number



Nov 14 14:45:47 mail dovecot: pop3-login: Disconnected (no auth attempts in 0 
secs): user=, rip=96.126.111.38, lip=108.61.22.11, TLS handshaking: 
SSL_accept() failed: Unknown error, session=3DqTMD1BKstgfm8m



Nov 14 14:45:49 mail dovecot: pop3-login: Disconnected (no auth attempts in 2 
secs): user=, rip=96.126.111.38, lip=108.61.22.11, TLS, 
session=CCqyMD1BdMtgfm8m



Was the Dovecot working well? 

Are there any good solutions to forbid this kind of behavior to enhance the 
mail server?



thanks.

Re: Let's Encrypt + Postfix TLS + iOS Mail

[lists]

  Have you tried to add the certs to the root store on your phone? I'm not on an iPhone, but that is what I did for Let's Encrypt. And it doesn't seem to always work.There was a thread I started a while ago on just buying certs. When I get around to it, that is my plan. This Let's Encrypt looks like a problem. I had to use the "der" files on the phone.https://letsencrypt.org/certificates/From: Steve JenkinsSent: Monday, November 14, 2016 6:08 PMTo: postfix usersSubject: Let's Encrypt + Postfix TLS + iOS MailI've had TLS working great on my Postfix servers for years, and I recently tried switching one of my boxes to a Let's Encrypt certificate. A Gmail test account using TLS on port 587 works fine, but the iOS mail client complains about the certificate being untrusted. Further digging shows it doesn't like the CA.I added the fullchain.pem file to the '/etc/postfix/ssl/cacert.pem' I use for 'smtpd_tls_CAfile' but that doesn't fix anything.Has anyone been able to get an iOS mail client to use a Postfix SMTP server with TLS?Here are my current (working) TLS-related entries in main.cf:# postconf -n | grep tlssmtp_tls_CAfile = $smtpd_tls_CAfilesmtp_tls_loglevel = 1smtp_tls_security_level = maysmtpd_tls_CAfile = /etc/postfix/ssl/cacert.pemsmtpd_tls_auth_only = yessmtpd_tls_cert_file = /etc/pki/tls/certs/example.com.crtsmtpd_tls_key_file = /etc/pki/tls/private/example.com.keysmtpd_tls_loglevel = 1smtpd_tls_received_header = yessmtpd_tls_security_level = mayIt breaks (on iOS) if I change the smtpd_tls_cert_file and smtpd_tls_key_file to the Let's Encrypt cert and key.Thanks,SteveJ

SV: Let's Encrypt + Postfix TLS + iOS Mail

[Sebastian Nielsen]

You need to be more clear here.

When you say Gmail account on port 587 I don’t entirely understand what you are 
doing. Are you using Gmail as upstream smarthost?

This does not then have any bearing on what clients see or react to, as your 
server acts as a proxy to Gmail.

 

If the iOS mail client complains about certificate being untrusted, its because 
the Let’s encrypt root is not imported or trusted, or that the entire chain 
excluding the root certificate, is not sent.

Note that Let’s encrypt is a pretty new actor so if your iOS device is old, it 
will always untrust. Try visiting a site that has Let’s encrypt deployed. If 
you get cert errors, this is the case.

 

 

Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Steve Jenkins
Skickat: den 15 november 2016 03:08
Till: postfix users 
Ämne: Let's Encrypt + Postfix TLS + iOS Mail

 

I've had TLS working great on my Postfix servers for years, and I recently 
tried switching one of my boxes to a Let's Encrypt certificate. A Gmail test 
account using TLS on port 587 works fine, but the iOS mail client complains 
about the certificate being untrusted. Further digging shows it doesn't like 
the CA.

 

I added the fullchain.pem file to the '/etc/postfix/ssl/cacert.pem' I use for 
'smtpd_tls_CAfile' but that doesn't fix anything.

 

Has anyone been able to get an iOS mail client to use a Postfix SMTP server 
with TLS?

 

Here are my current (working) TLS-related entries in main.cf  :

 

# postconf -n | grep tls

smtp_tls_CAfile = $smtpd_tls_CAfile

smtp_tls_loglevel = 1

smtp_tls_security_level = may

smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem

smtpd_tls_auth_only = yes

smtpd_tls_cert_file = /etc/pki/tls/certs/example.com.crt

smtpd_tls_key_file = /etc/pki/tls/private/example.com.key

smtpd_tls_loglevel = 1

smtpd_tls_received_header = yes

smtpd_tls_security_level = may

 

It breaks (on iOS) if I change the smtpd_tls_cert_file and smtpd_tls_key_file 
to the Let's Encrypt cert and key.

 

Thanks,

 

SteveJ



smime.p7s
Description: S/MIME Cryptographic Signature

Re: postfix only resolving ipv6 name from google server

[James D. Parra]

James D. Parra:
> The logs are as follows;
> 
> Nov 12 13:49:05 mail postfix/smtp[15313]: connect to 
> alt1.aspmx.l.google.com[2607:f8b0:4001:c0f::1a]:25: Network is unreachable
> Nov 12 13:49:05 mail postfix/smtp[15313]: connect to 
> alt2.aspmx.l.google.com[2607:f8b0:4002:c03::1a]:25: Network is unreachable
> Nov 12 13:49:05 mail postfix/smtp[15313]: connect to 
> aspmx.l.google.com[2607:f8b0:400e:c04::1a]:25: Network is unreachable
> Nov 12 13:49:05 mail postfix/smtp[15313]: connect to 
> aspmx2.googlemail.com[2607:f8b0:4001:c0f::1b]:25: Network is unreachable
> Nov 12 13:49:05 mail postfix/smtp[15313]: connect to 
> aspmx3.googlemail.com[2607:f8b0:4002:c03::1b]:25: Network is unreachable

The problem is that your Postfix is configured to try IPv6 before IPv4.
Don't do that. Instead, set 

smtp_address_preference = any

which is the default since Postfix 2.9.

If you don't have IPv6 connectivity, don't enable it in main.cf:

inet_protocols = ipv4

Wietse

~~
Thank you Wietse.

That resolved the issue.

Best regards,

James

Re: Let's Encrypt + Postfix TLS + iOS Mail

[Viktor Dukhovni]

> On Nov 14, 2016, at 9:08 PM, Steve Jenkins  wrote:
> 
> # postconf -n | grep tls
> smtp_tls_CAfile = $smtpd_tls_CAfile
> smtp_tls_loglevel = 1
> smtp_tls_security_level = may

The above, being outgoing (SMTP client) settings have no bearing
on the TLS behaviour of your server when receiving mail.

> smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem

This is unlikely to be useful in constructing a complete
chain for Let's Encrypt if it is certs for cacert.org.

> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/pki/tls/certs/example.com.crt
> smtpd_tls_key_file = /etc/pki/tls/private/example.com.key

You *really* should not use "example" certs/keys.

> It breaks (on iOS) if I change the smtpd_tls_cert_file and smtpd_tls_key_file 
> to the Let's Encrypt cert and key.

If iOS is happy with random "example" certs, perhaps it is
because it was explicitly configured to trust these.

In any case the right thing to do is in fact to populate the
cert file with your server's Let's Encrypt certificate and
issuing CA certificate in that order.  The key file must have
the corresponding private key.

-- 
Viktor.

Let's Encrypt + Postfix TLS + iOS Mail

[Steve Jenkins]

I've had TLS working great on my Postfix servers for years, and I recently
tried switching one of my boxes to a Let's Encrypt certificate. A Gmail
test account using TLS on port 587 works fine, but the iOS mail client
complains about the certificate being untrusted. Further digging shows it
doesn't like the CA.

I added the fullchain.pem file to the '/etc/postfix/ssl/cacert.pem' I use
for 'smtpd_tls_CAfile' but that doesn't fix anything.

Has anyone been able to get an iOS mail client to use a Postfix SMTP server
with TLS?

Here are my current (working) TLS-related entries in main.cf:

# postconf -n | grep tls
smtp_tls_CAfile = $smtpd_tls_CAfile
smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/pki/tls/certs/example.com.crt
smtpd_tls_key_file = /etc/pki/tls/private/example.com.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may

It breaks (on iOS) if I change the smtpd_tls_cert_file and
smtpd_tls_key_file to the Let's Encrypt cert and key.

Thanks,

SteveJ

Re: Dovecot SASL

[Wietse Venema]

Silvio Siefke:
> Hello, 
> 
> i install today postfix and all work, I think so, but SMTP-AUTH make
> trouble again. 
> 
> I become:
> 
> 554 5.7.1 : Helo command rejected: Host not found
> 
> Have someone Idea what can change? When I use SMTP-AUTH why check helo? 

Because you configured Postfix to reject unknown names with
reject_unknown_helo_hostname.

Wietse

Re: use of dash [and other] characters in parameter names

[Wietse Venema]

btb:
> by chance, i happened to create a parameter which used a dash in the
> name, and was referencing it in another parameter, e.g.:
> 
> foo-param = foo
> bar_param = ${foo-param}
> 
> upon restart, postfix complained about this:
> 
> postconf: warning: macro name syntax error: "foo-param"
> postconf: fatal: macro processing error

With $name and ${name, the name is limited to the character set
[a-zA-z0-9_]. Allowing other characters in those contexts names is
too problematic. It's not possible to rely on spaces to end the name.

Wietse

Re: postfix only resolving ipv6 name from google server

[Wietse Venema]

James D. Parra:
> The logs are as follows;
> 
> Nov 12 13:49:05 mail postfix/smtp[15313]: connect to 
> alt1.aspmx.l.google.com[2607:f8b0:4001:c0f::1a]:25: Network is unreachable
> Nov 12 13:49:05 mail postfix/smtp[15313]: connect to 
> alt2.aspmx.l.google.com[2607:f8b0:4002:c03::1a]:25: Network is unreachable
> Nov 12 13:49:05 mail postfix/smtp[15313]: connect to 
> aspmx.l.google.com[2607:f8b0:400e:c04::1a]:25: Network is unreachable
> Nov 12 13:49:05 mail postfix/smtp[15313]: connect to 
> aspmx2.googlemail.com[2607:f8b0:4001:c0f::1b]:25: Network is unreachable
> Nov 12 13:49:05 mail postfix/smtp[15313]: connect to 
> aspmx3.googlemail.com[2607:f8b0:4002:c03::1b]:25: Network is unreachable

The problem is that your Postfix is configured to try IPv6 before IPv4.
Don't do that. Instead, set 

smtp_address_preference = any

which is the default since Postfix 2.9.

If you don't have IPv6 connectivity, don't enable it in main.cf:

inet_protocols = ipv4

Wietse

Re: postfix only resolving ipv6 name from google server

[James D. Parra]

> Let me know if you need any other details.

Well, this would be a good time to post the output of "postconf -n",
"postconf -Mf" (assuming sufficiently recent version of Postfix, else
the master.cf pruned of comment lines) and any pertinent transport table
entries.

Also output from prior delivery attempts for the message in question, those may
have tried IPv4.  When both are enabled, the choice of which to prefer is 
random.
If you don't have IPv6 connectivity, you really should disable IPv6 (by setting
inet_protocols=ipv4).  So just because the last delivery fails with IPv6, does
not mean that IPv4 was never tried.

-- 
Many thanks Viktor.

Changing 'inet_protocols=all' to 'inet_protocols=ipv4' solved the problem.

Best regards,

James

Re: postfix only resolving ipv6 name from google server

[Viktor Dukhovni]

> On Nov 14, 2016, at 5:14 PM, James D. Parra  wrote:
> 
> The logs are as follows;
> 
> Nov 12 13:49:05 mail postfix/smtp[15313]: connect to 
> alt1.aspmx.l.google.com[2607:f8b0:4001:c0f::1a]:25: Network is unreachable
> Nov 12 13:49:05 mail postfix/smtp[15313]: connect to 
> alt2.aspmx.l.google.com[2607:f8b0:4002:c03::1a]:25: Network is unreachable
> Nov 12 13:49:05 mail postfix/smtp[15313]: connect to 
> aspmx.l.google.com[2607:f8b0:400e:c04::1a]:25: Network is unreachable
> Nov 12 13:49:05 mail postfix/smtp[15313]: connect to 
> aspmx2.googlemail.com[2607:f8b0:4001:c0f::1b]:25: Network is unreachable
> Nov 12 13:49:05 mail postfix/smtp[15313]: connect to 
> aspmx3.googlemail.com[2607:f8b0:4002:c03::1b]:25: Network is unreachable
> Nov 12 13:49:05 mail postfix/smtp[15313]: E63C72140CE5: 
> to=, relay=none, delay=433194, 
> delays=433193/0.09/0.56/0, dsn=4.4.1, status=deferred (connect to 
> aspmx3.googlemail.com[2607:f8b0:4002:c03::1b]:25: Network is unreachable)
> Nov 12 13:49:05 mail postfix/qmgr[2760]: E63C72140CE5: 
> from=, status=expired, returned to sender
> Nov 12 13:49:05 mail postfix/cleanup[15180]: 768CC21408A1: 
> message-id=<20161112214905.768cc2140...@smtp-relay.musicreports.com>
> Nov 12 13:49:05 mail postfix/bounce[15310]: E63C72140CE5: sender non-delivery 
> notification: 768CC21408A1
> Nov 12 13:49:05 mail postfix/qmgr[2760]: 768CC21408A1: from=<>, size=26053, 
> nrcpt=1 (queue active)
> Nov 12 13:49:05 mail postfix/qmgr[2760]: E63C72140CE5: removed
> 
> 
> Let me know if you need any other details.

Well, this would be a good time to post the output of "postconf -n",
"postconf -Mf" (assuming sufficiently recent version of Postfix, else
the master.cf pruned of comment lines) and any pertinent transport table
entries.

Also output from prior delivery attempts for the message in question, those may
have tried IPv4.  When both are enabled, the choice of which to prefer is 
random.
If you don't have IPv6 connectivity, you really should disable IPv6 (by setting
inet_protocols=ipv4).  So just because the last delivery fails with IPv6, does
not mean that IPv4 was never tried.

-- 
Viktor.

Dovecot SASL

[Silvio Siefke]

Hello, 

i install today postfix and all work, I think so, but SMTP-AUTH make
trouble again. 

I become:

554 5.7.1 : Helo command rejected: Host not found

Have someone Idea what can change? When I use SMTP-AUTH why check helo? 

Thank you 
Silvio

Log
Nov 14 21:54:53 postfix/smtpd[24576]: NOQUEUE: reject: RCPT from 
p5DC5FEA9.dip0.t-ipconnect.de[93.197.254.169]: 554 5.7.1 
: Helo command rejected: Host not found; 
from= to= proto=ESMTP 
helo=

[root@vps296466 postfix]# postconf -n
alias_database = $alias_maps
alias_maps = hash:/etc/postfix/aliases
anvil_rate_time_unit = 60s
bounce_size_limit = 8192
command_directory = /usr/bin
compatibility_level = 2
daemon_directory = /usr/lib/postfix/bin
data_directory = /var/lib/postfix
disable_vrfy_command = yes
home_mailbox = Maildir/
html_directory = no
inet_interfaces = 127.0.0.1, 164.132.55.246
inet_protocols = ipv4
mail_owner = postfix
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
message_size_limit = 2048
meta_directory = /etc/postfix
mydestination = $myhostname, localhost.$mydomain, localhost
mydomain = silviosiefke.com
myhostname = fr-sb.silviosiefke.com
mynetworks = 127.0.0.0/8
mynetworks_style = host
myorigin = $myhostname
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
sample_directory = /etc/postfix
sendmail_path = /usr/bin/sendmail
setgid_group = postdrop
shlib_directory = /usr/lib/postfix
smtp_tls_cert_file = /etc/letsencrypt/live/fr-sb.silviosiefke.com/fullchain.pem
smtp_tls_ciphers = high
smtp_tls_key_file = /etc/letsencrypt/live/fr-sb.silviosiefke.com/privkey.pem
smtp_tls_loglevel = 1
smtp_tls_mandatory_ciphers = high
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3
smtp_tls_protocols = !SSLv2,!SSLv3
smtp_tls_security_level = encrypt
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtpd_banner = $myhostname ESMTP
smtpd_client_connection_count_limit = 20
smtpd_client_connection_rate_limit = 20
smtpd_client_message_rate_limit = 50
smtpd_client_recipient_rate_limit = 50
smtpd_client_restrictions = reject_unknown_client_hostname
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_helo_hostname, 
reject_unknown_helo_hostname, reject_non_fqdn_helo_hostname
smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/blacklist, 
reject_unknown_recipient_domain, reject_non_fqdn_recipient, 
reject_unverified_recipient, permit_mynetworks, reject_unauth_destination, 
reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, 
reject_rhsbl_client multi.uribl.com, check_policy_service inet:127.0.0.1:10030
smtpd_sasl_auth_enable = yes
smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/fr-sb.silviosiefke.com/fullchain.pem
smtpd_tls_ciphers = high
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem
smtpd_tls_key_file = /etc/letsencrypt/live/fr-sb.silviosiefke.com/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_protocols = !SSLv2,!SSLv3
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
soft_bounce = no
tls_export_cipherlist = 
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:ALL:!aNULL:!ADH:!3DES:!EXP:!RC4:!kKRB5:!aDSS:!DES:!aPSK:!kECDH:!RC2:!IDEA:!SEED:!CAMELLIA:!AES128-SHA
tls_preempt_cipherlist = 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/virtual
virtual_mailbox_base = /
virtual_mailbox_domains = $mydomain

[root@vps296466 postfix]# dovecot -n
# 2.2.26.0 (23d1de6): /etc/dovecot/dovecot.conf
# OS: Linux 4.8.6-1-ARCH x86_64  
auth_cache_size = 10 M
first_valid_uid = 1000
listen = 164.132.55.246
mail_location = maildir:~/Maildir
mail_plugin_dir = /usr/lib/dovecot
mbox_write_locks = fcntl
mmap_disable = yes
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
auto = subscribe
special_use = \Junk
  }
  mailbox Sent {
auto = subscribe
special_use = \Sent
  }
  mailbox "Sent Messages" {
special_use = \Sent
  }
  mailbox Trash {
auto = subscribe
special_use = \Trash
  }
  prefix = 
}
passdb {
  driver = pam
}
plugin {
  sieve = 

postfix only resolving ipv6 name from google server

[James D. Parra]

Hello Postfix Group,

When attempting to send an email to a particular domain,lowlypalace.io, postfix 
only gets the ipv6 address and does not fall back to the ipv4 address. For 
example;

status=deferred (connect to aspmx2.googlemail.com[2607:f8b0:4001:c08::1a]:25: 
Network is unreachable)

There is no second attempt for the ipv4 address, although it is resolvable from 
the mail server;

  ping alt2.aspmx.l.google.com
PING alt2.aspmx.l.google.com (173.194.219.26) 56(84) bytes of data.
64 bytes from ya-in-f26.1e100.net (173.194.219.26): icmp_req=1 ttl=39 time=65.7 
ms
64 bytes from ya-in-f26.1e100.net (173.194.219.26): icmp_req=2 ttl=39 time=65.7 
ms


Interestingly, I see gmail addresses working when the ipv6 ip is not reachable;

Nov 14 11:24:33 mail postfix/qmgr[2760]: 144DB21408CA: from=, 
size=151283, nrcpt=1 (queue active)
Nov 14 11:24:33 mail postfix/smtp[2587]: connect to 
gmail-smtp-in.l.google.com[2607:f8b0:400e:c02::1a]:25: Network is unreachable
Nov 14 11:24:34 mail postfix/smtp[2587]: 144DB21408CA: to=, 
relay=gmail-smtp-in.l.google.com[74.125.199.27]:25, delay=1.4, 
delays=0.04/0.06/0.59/0.72, dsn=2.0.0, status=sent (250 2.0.0 OK 1479151474 
z63si23334266pff.293 - gsmtp)



Is there anything I need to change in postfix to help resolve this?

Thank you,

James 

Re: Full encryption

[Karel]

> On 2016-11-14 05:34, Peter wrote:
> 3.  Make sure you have plenty of RAM, and disable swap if you want to
> make absolutely certain that plain text won't get swapped out to disk.

You don't have to disable swap. Swap partition can be encrypted too, as
well as /home, /var or wherever emails are stored. This is easy to set
up in Linux with LUKS/cryptsetup.

Karel