Re: [Postfix] Deferred queue ...

[Viktor Dukhovni]

On Wed, Dec 16, 2015 at 09:47:48AM -0600, Noel Jones wrote:

> > Second question, the domain.aaa and domain.bbb returned by the
> > command on the deferred queue correspond to the sender domain or the
> > recipient domain ?
> 
> recipient.

With "qshape -s", the grouping is by sender:

Usage: qshape.pl [ -s ] [ -p ] [ -m  ] [ -l ]
[ -b  ] [ -t  ] [ -w  ]
[ -N  ] [ -n  ]
[ -c  ] [  ... ]
The 's' option shows sender domain counts.
The 'p' option shows address counts by for parent domains.
Parent domains are shown with a leading '.' before the domain name.
Parent domains are only shown if the the domain is not a TLD, and at
least  (default 5) subdomains are shown in the output.

The bucket age ranges in units of  minutes are
[0,1), [1,2), [2,4), [4,8), [8, 16), ... i.e.:
the first bucket is [0, bucket_time) minutes
the second bucket is [bucket_time, 2*bucket_time) minutes
the third bucket is [2*bucket_time, 4*bucket_time) minutes...
'-l' makes the ages linear, the number of buckets shown is 

The default summary is for the incoming and active queues. An explicit
list of queue names can be given on the command line. Non-absolute queue
names are interpreted relative to the Postfix queue directory. Use
 to specify a non-default Postfix instance.  Values of
the main.cf queue_directory parameter that use variable expansions are
not supported. If necessary, use explicit absolute paths for all queues.

-- 
Viktor.

Re: postfix and multiple TLS certificates (SNI support?)

[Michael Storz]

Am 2015-12-16 16:26, schrieb Alice Wonder:


But with port 25, certificate authorities do not matter, so an admin
running the same smtp server on multiple hostnames can generate a new
self-signed cert at no cost every time they add a domain that resolves
to that IP address.

Thus even with multiple domains resolving to the same IP address, I
don't see a need for port 25 to have more than one cert.

Am I missing something?


The goal ist to prevent an active  man-in-the-middle (MITM) attack. To 
reach this goal you need an authenticated TLS connection from the SMTP 
client to the SMTP server. At the moment you have two possibilities to 
authenticate a TLS connection:


- using DNSSEC/DANE which is finally standardized in RFC 7672
- using the traditional PKIX method, which is not standardized and 
therefore not really used at the moment


The process of authentication uses two steps

- checking if the public key belongs to the domain
- checking if the domain you use as a reference identifier is related to 
the domain from step one (this is the part about SNI and checking the 
reference identifier)


For the PKIX method this means you have to verify the certificate (which 
includes several steps) and to check if you trust the signer of the 
certificte (CA). Only then you can trust that the key really belongs to 
the owner of the domain in the certificate (this is only a very 
simplified description of the whole process, read the relevant 
literature about the problems with this approach). If the certificate is 
self-signed or signed by a private CA the certifiacte could as well be 
issued by a man-in-the-middle. Using an unauthenticated TLS connection 
prevents passive attacks (eavesdropping) but not active attacks.


Therefore certificate authorities do matter for every protocol which 
uses TLS and the traditional PKIX method of authentication.


Michael

Re: postfix and multiple TLS certificates (SNI support?)

[Alice Wonder]

On 12/16/2015 09:06 AM, Michael Storz wrote:

Am 2015-12-16 16:26, schrieb Alice Wonder:


But with port 25, certificate authorities do not matter, so an admin
running the same smtp server on multiple hostnames can generate a new
self-signed cert at no cost every time they add a domain that resolves
to that IP address.

Thus even with multiple domains resolving to the same IP address, I
don't see a need for port 25 to have more than one cert.

Am I missing something?


The goal ist to prevent an active  man-in-the-middle (MITM) attack. To
reach this goal you need an authenticated TLS connection from the SMTP
client to the SMTP server. At the moment you have two possibilities to
authenticate a TLS connection:

- using DNSSEC/DANE which is finally standardized in RFC 7672
- using the traditional PKIX method, which is not standardized and
therefore not really used at the moment

The process of authentication uses two steps

- checking if the public key belongs to the domain
- checking if the domain you use as a reference identifier is related to
the domain from step one (this is the part about SNI and checking the
reference identifier)

For the PKIX method this means you have to verify the certificate (which
includes several steps) and to check if you trust the signer of the
certificte (CA). Only then you can trust that the key really belongs to
the owner of the domain in the certificate (this is only a very
simplified description of the whole process, read the relevant
literature about the problems with this approach). If the certificate is
self-signed or signed by a private CA the certifiacte could as well be
issued by a man-in-the-middle. Using an unauthenticated TLS connection
prevents passive attacks (eavesdropping) but not active attacks.

Therefore certificate authorities do matter for every protocol which
uses TLS and the traditional PKIX method of authentication.

Michael



The problem is there is no agreed upon list of certificate authorities 
that must be used.


So my signed certificate may be signed by a certificate authority your 
server doesn't trust.


As there is no opportunity for user interaction when the CA isn't 
trusted by a particular server, that's a problem, so they don't require 
CA validation.


Hence why DANE is needed to avoid MITM and guarantee encrypted transmission.

postscreen: DNSBL rank not seen in logs for some ip addresses

[btb]

hi-

i've become accustomed to seeing log passages like this:

>grep -iF '[142.4.19.85]:52366' mail.log
Dec 16 09:41:09 mta1 postfix/postscreen[27678]: CONNECT from 
[142.4.19.85]:52366 to [10.3.70.6]:25
Dec 16 09:41:15 mta1 postfix/postscreen[27678]: DNSBL rank 5 for 
[142.4.19.85]:52366
Dec 16 09:41:15 mta1 postfix/tlsproxy[29186]: CONNECT from 
[142.4.19.85]:52366
Dec 16 09:41:15 mta1 postfix/tlsproxy[29186]: Anonymous TLS connection 
established from [142.4.19.85]:52366: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Dec 16 09:41:15 mta1 postfix/postscreen[27678]: NOQUEUE: reject: RCPT 
from [142.4.19.85]:52366: 550 5.7.1 Service unavailable; client 
[142.4.19.85] blocked using zen.spamhaus.org; 
from=, 
to=, proto=ESMTP, 
helo=
Dec 16 09:41:15 mta1 postfix/postscreen[27678]: HANGUP after 0.54 from 
[142.4.19.85]:52366 in tests after SMTP handshake
Dec 16 09:41:15 mta1 postfix/postscreen[27678]: DISCONNECT 
[142.4.19.85]:52366

Dec 16 09:41:15 mta1 postfix/tlsproxy[29186]: DISCONNECT [142.4.19.85]:52366

but sometimes, the DNSBL rank seems to be absent:

>grep -iF '[104.47.32.71]:33498' mail.log.1
Dec 10 14:20:36 mta1 postfix/postscreen[32607]: CONNECT from 
[104.47.32.71]:33498 to [10.3.70.6]:25
Dec 10 14:20:42 mta1 postfix/tlsproxy[2980]: CONNECT from 
[104.47.32.71]:33498
Dec 10 14:20:42 mta1 postfix/tlsproxy[2980]: Anonymous TLS connection 
established from [104.47.32.71]:33498: TLSv1.2 with cipher 
ECDHE-RSA-AES256-SHA384 (256/256 bits)
Dec 10 14:20:42 mta1 postfix/postscreen[32607]: NOQUEUE: reject: RCPT 
from [104.47.32.71]:33498: 450 4.3.2 Service currently unavailable; 
from=, to=, proto=ESMTP, 
helo=
Dec 10 14:20:42 mta1 postfix/postscreen[32607]: HANGUP after 0.64 from 
[104.47.32.71]:33498 in tests after SMTP handshake
Dec 10 14:20:42 mta1 postfix/postscreen[32607]: PASS NEW 
[104.47.32.71]:33498

Dec 10 14:20:42 mta1 postfix/tlsproxy[2980]: DISCONNECT [104.47.32.71]:33498
Dec 10 14:20:42 mta1 postfix/postscreen[32607]: DISCONNECT 
[104.47.32.71]:33498


is this expected?  if not, how can i determine why it's happening?

thanks
-ben

Re: postfix and multiple TLS certificates (SNI support?)

[Alice Wonder]

On 12/16/2015 02:03 AM, Michael Storz wrote:

Am 2015-12-15 20:36, schrieb Viktor Dukhovni:

On Mon, Dec 14, 2015 at 04:34:58PM +, Viktor Dukhovni wrote:


So, we've managed to hold off on offering SNI support for a decade
since TLS was integrated into Postfix 2.2.  I just wanted to see
whether anyone still wanted it in Postfix, but perhaps if they
really did they've moved on to other solutions.


So far I'm not sensing any burning desire for server-side SNI in
Postfix, and it is quite late in the 3.1 cycle, so if we're going
to do SNI, it'll be in 3.2 or later.

At present, the Postfix SMTP client only sends SNI with DANE, where
it is clear what name to ask for (the TLSA base domain).  With
"verify" and "secure" it is far from clear that sending SNI would
do more good than harm, and we match multiple names or name patterns,
so the choice of what to send in SNI is not so clear.

I think we're set for now with Postfix as-is.


Could you explain, why you think sending SNI could harm?

Lets look at the different cases assuming no DNSSEC is used. In the
general case the only trustable reference identifier therefore is the
domain of the recipient address. If you do not send SNI then the server
sends the default cert attached to the ip address of the server (TLS
connection endpoint). If it was possible to put all hosted domains into
the SAN of the cert you get a match for your reference identifier and if
the cert could be verified you get an authenticated TLS connection. If
the domain was not in the set of presented identifiers at the maximum
you get a trusted TLS connection (cert verified) but no authenticated
TLS connection.


But with port 25, certificate authorities do not matter, so an admin 
running the same smtp server on multiple hostnames can generate a new 
self-signed cert at no cost every time they add a domain that resolves 
to that IP address.


Thus even with multiple domains resolving to the same IP address, I 
don't see a need for port 25 to have more than one cert.


Am I missing something?

Re: [Postfix] Deferred queue ...

[Noel Jones]

On 12/16/2015 3:55 AM, Baptiste Lhoste wrote:
> 
> But our deferred queue contains almost 100 000 emails :
> qshape -s deferred | head
>T  5 10 20 40 80  160   320 640 
> 1280 1280+
>  TOTAL 98743  0  0  0  0  0 8233 20178 39254
> 31078 0
>   domain.aaa98741  0  0  0  0  0 8233 20177 39254
> 31077 0
>   domain.bbb   2  0  0  0  0  00 1 0
> 1 0
> 
> I thought that when the active queue was empty, postfix moves an
> email from the incoming queue and one email from the deferred queue
> to the active queue, and with that the deferred queue should be
> decreasing.
> 
> Why it is not the case ?

Details will be in the log file. My guess is the destination is
marked "dead" for some temporary error, with a few retries at
$maximal_backoff_time (default 4000s) to see if the destination will
accept mail.


> 
> Second question, the domain.aaa and domain.bbb returned by the
> command on the deferred queue correspond to the sender domain or the
> recipient domain ?

recipient.



  -- Noel Jones

Re: postscreen: DNSBL rank not seen in logs for some ip addresses

[Wietse Venema]

btb:
> hi-
> 
> i've become accustomed to seeing log passages like this:
> 
>  >grep -iF '[142.4.19.85]:52366' mail.log
> Dec 16 09:41:09 mta1 postfix/postscreen[27678]: CONNECT from 
> [142.4.19.85]:52366 to [10.3.70.6]:25
> Dec 16 09:41:15 mta1 postfix/postscreen[27678]: DNSBL rank 5 for 
> [142.4.19.85]:52366
> Dec 16 09:41:15 mta1 postfix/tlsproxy[29186]: CONNECT from 

The client was listed at some DNSBL. BTW, there would also have
been dnsblog logging for that IP address.

> but sometimes, the DNSBL rank seems to be absent:
> 
>  >grep -iF '[104.47.32.71]:33498' mail.log.1
> Dec 10 14:20:36 mta1 postfix/postscreen[32607]: CONNECT from 
> [104.47.32.71]:33498 to [10.3.70.6]:25
> Dec 10 14:20:42 mta1 postfix/tlsproxy[2980]: CONNECT from 

The client was not listed at some DNSBL, or the dnsblog daemon
logged a DNS lookup timeout error. Use your own DNS server, don't
share queries with other organizations.

Wietse

Re: sasl authentication - how to hash password maps

[Koko Wijatmoko]

On Wed, 16 Dec 2015 09:08:34 +0100
Zalezny Niezalezny  wrote:

> Is it possible to hash that password some how ? This password shouldnt be
> visible for the user.
> If yes, how to do it then ?
> 
the answer is here.. password must be plain-text:

http://www.postfix.org/SASL_README.html#client_sasl_enable

"chmod 600" for the sasl_passwd + sasl_passwd.db is enough.

sasl authentication - how to hash password maps

[Zalezny Niezalezny]

Dear Colleagues,

I`m trying to establish TLS connection between our postfix MTA and Postfix
relay server protected by password.

At the moment my password map file looks like this. Plain text with domain,
username and password.

[root@server01 postfix]# cat sasl_passwd
relay01.local test:testXX


Is it possible to hash that password some how ? This password shouldnt be
visible for the user.
If yes, how to do it then ?



Thanks in advance for any hints.



Zalezny

[Postfix] Deferred queue ...

[Baptiste Lhoste]

Hi everybody,

Could someone help me to understand the following situation :

Our active queue seems empty :
qshape -s active | head
 T  5 10 20 40 80 160 320 640 
1280 1280+
  TOTAL  0  0  0  0  0  0   0   0 0
0 0



Same thing for our incoming queue :
qshape -s incoming | head
 T  5 10 20 40 80 160 320 640 
1280 1280+
  TOTAL  0  0  0  0  0  0   0   0 0
0 0


But our deferred queue contains almost 100 000 emails :
qshape -s deferred | head
   T  5 10 20 40 80  160   320 640  
1280 1280+
 TOTAL 98743  0  0  0  0  0 8233 20178 39254 
31078 0
  domain.aaa98741  0  0  0  0  0 8233 20177 39254 
31077 0

  domain.bbb   2  0  0  0  0  00 1 0 1 0

I thought that when the active queue was empty, postfix moves an email 
from the incoming queue and one email from the deferred queue to the 
active queue, and with that the deferred queue should be decreasing.


Why it is not the case ?

Second question, the domain.aaa and domain.bbb returned by the command 
on the deferred queue correspond to the sender domain or the recipient 
domain ?


Thanks in advance,

Baptiste Lhoste.

Re: postfix and multiple TLS certificates (SNI support?)

[Michael Storz]

Am 2015-12-15 20:36, schrieb Viktor Dukhovni:

On Mon, Dec 14, 2015 at 04:34:58PM +, Viktor Dukhovni wrote:


So, we've managed to hold off on offering SNI support for a decade
since TLS was integrated into Postfix 2.2.  I just wanted to see
whether anyone still wanted it in Postfix, but perhaps if they
really did they've moved on to other solutions.


So far I'm not sensing any burning desire for server-side SNI in
Postfix, and it is quite late in the 3.1 cycle, so if we're going
to do SNI, it'll be in 3.2 or later.

At present, the Postfix SMTP client only sends SNI with DANE, where
it is clear what name to ask for (the TLSA base domain).  With
"verify" and "secure" it is far from clear that sending SNI would
do more good than harm, and we match multiple names or name patterns,
so the choice of what to send in SNI is not so clear.

I think we're set for now with Postfix as-is.


Could you explain, why you think sending SNI could harm?

Lets look at the different cases assuming no DNSSEC is used. In the 
general case the only trustable reference identifier therefore is the 
domain of the recipient address. If you do not send SNI then the server 
sends the default cert attached to the ip address of the server (TLS 
connection endpoint). If it was possible to put all hosted domains into 
the SAN of the cert you get a match for your reference identifier and if 
the cert could be verified you get an authenticated TLS connection. If 
the domain was not in the set of presented identifiers at the maximum 
you get a trusted TLS connection (cert verified) but no authenticated 
TLS connection.


If you send the recipient domain as SNI the server checks its certs:

- if it only has a default cert, it sends the default cert
- if it has multiple certs, it checks the presented identifiers (SAN of 
cert) for a match with the SNI.

  * if there is no match, it sends the default cert,
  * if there is a match it sends the matching cert.

Therefore, if you send SNI and get back the default cert, there is no 
difference to not sending SNI. If you get back a different cert than the 
default cert, your reference identifier which you send as SNI is among 
the presented identifiers of the cert. Therefore you have a match and 
that is exactly what you want.


For the single recipient email I cannot see any possible harm.

If you have a multi-recipient email and

- the domain of all recipients ist the same there is no difference to 
the single-recipient email

- if the domains are different and
  * if the connection endpoints of the TLS connections are different, 
you must create multiple TLS connections and each TLS connection behaves 
the same way as in the single recipient email case

  * if the connection endpoints are the same
+ you could ignore this and still use a different connection for 
every domain as in the case above
+ you could try to optimize the number of connections and use the 
domain of the first recipient for SNI and then check for the next 
recipient if the domain is included in the presented identifiers

  . if yes reuse the TLS connection
  . if not open a new connection with that domain as SNI
In both cases you get back either the default cert and maybe a match 
or another cert with a match


Therefore if you send SNI you are getting the highest chance for a match 
for your reference identifier and therefore for an authenicated TLS 
connection. The cost would be the higher number of connections is some 
cases. Thats the only harm I can see. But the benefit of more possible 
matches is much more important.


Michael